* Linux 3.11-rc2 @ 2013-07-21 19:53 Linus Torvalds 2013-07-21 21:07 ` Tobias Klausmann ` (3 more replies) 0 siblings, 4 replies; 71+ messages in thread From: Linus Torvalds @ 2013-07-21 19:53 UTC (permalink / raw) To: Linux Kernel Mailing List So it's been another week, and -rc2 is out there. The patch looks a bit odd, because by bulk 95% of the patch is just the removal of the CSR staging driver that wasn't getting any traction, so the diffstat (and the dirstat in particular) is not very interesting or readable, since that driver removal basically overshadows everything else. But I do admit to love seeing code removal patches. And of the rest of the patch, a noticeable part is all those one-liners all over that just remove the __cpuinit markers that people agreed were just more pain than gain to maintain. We had already made the markers be no-ops earlier, so they didn't matter for code generation, and here in rc2 they get actually removed. End result: we have two separate events that generate a lot of noise in the patch, but aren't really interesting per se. They do make the patch harder to read, though. Ignoring those noisy parts of the patch, there's a couple of things worth noting about rc2. I think most of the patches here are nice fixes, but I wanted to give two heads-ups: (a) the O_TMPFILE flag that is new to 3.11 has been going through a few ABI/API cleanups (and a few fixes to the implementation too), but I think we're done now. So if you're interested in the concept of unnamed temporary files, go ahead and test it out. The lack of name not only gets rid of races/complications with filename generation, it can make the whole thing more efficient since you don't have the directory operations that can cause serializing IO etc. (b) we had a late change to how ACPI backlight handling is done on certain machines, and while this kind of thing really shouldn't be done outside the merge window, I ended up pulling it anyway. But I'd *really* like to have people test this thing particularly on laptops with intel-based graphics. It should only matter (and hopefully improve things) for the newer ones with BIOSes designed for Windows 8, but hey, the more testing, the better. Backlight handling has been painful before, so I'm mentioning this explicitly. Anyway, apart from those two issues, I think the rest is pretty normal for rc2. It started out a bit slow, but I think it ended up fairly normal. Apart from the already mentioned issues, we've got drm stuff (radeon in particular), some driver core fixes, s390/mips/arm/x86 updates, sound drivers, ext4/btrfs fixes, yadda yadda. The shortlog since -rc1 is appended. Linus --- Aaro Koskinen (1): MIPS: tlbex: fix broken build in v3.11-rc1 Aaron Lu (2): ACPICA: expose OSI version ACPI / video: no automatic brightness changes by win8-compatible firmware Aaron Plattner (1): ALSA: hda - Add new GPU codec ID to snd-hda Al Viro (2): allow O_TMPFILE to work with O_WRONLY livelock avoidance in sget() Alex Deucher (16): drm/radeon/hdmi: make sure we have an afmt block assigned drm/radeon/dpm: disable gfx PG on PALM drm/radeon: Disable dma rings for bo moves on r6xx drm/radeon: implement bo copy callback using CP DMA (v2) drm/radeon: use CP DMA on r6xx for bo moves drm/radeon: add fault decode function for cayman/TN (v2) drm/radeon: add fault decode function for SI (v2) drm/radeon: add fault decode function for CIK drm/radeon: allow selection of alignment in the sub-allocator drm/radeon: align VM PTBs (Page Table Blocks) to 32K drm/radeon/dpm/sumo: handle boost states properly when forcing a perf level drm/radeon: add a module parameter to disable aspm drm/radeon: fix an endian bug in atom table parsing drm/radeon/dpm: fix atom vram table parsing drm/radeon/dpm/atom: fix broken gcc harder drm/radeon/dpm: add debugfs support for RS780/RS880 (v3) Alexandre Belloni (2): iio: Fix iio_channel_has_info iio: inkern: fix iio_convert_raw_to_processed_unlocked Anatol Pomozov (1): ext4: rate limit printk in buffer_io_error() Andre Heider (1): drm/radeon/dpm/atom: restructure logic to work around a compiler bug Catalin Marinas (1): arm64: Only enable local interrupts after the CPU is marked online Chanwoo Choi (1): PM / Sleep: Fix comment typo in pm_wakeup.h Chen Gang (1): arm64: add '#ifdef CONFIG_COMPAT' for aarch32_break_handler() Chris Wilson (3): drm/i915: Fix write-read race with multiple rings drm/i915: Fix incoherence with fence updates on Sandybridge+ Revert "drm/i915: Workaround incoherence between fences and LLC across multiple CPUs" Christian König (2): drm/radeon: fix UVD fence emit drm/radeon: never unpin UVD bo v3 Dan Carpenter (1): svcrdma: underflow issue in decode_write_list() Daniel Baluta (1): ndisc: bool initializations should use true and false Daniel Mack (1): regmap: cache: bail in regmap_async_complete() for bus-less maps Daniel Vetter (2): drm/i915: reinit status page registers after gpu reset drm/i915: fix up ring cleanup for the i830/i845 CS tlb w/a Dave Jones (1): linked-list: Remove __list_for_each David Jeffery (1): lockd: protect nlm_blocked access in nlmsvc_retry_blocked David S. Miller (1): net: Fix sysfs_format_mac() code duplication. Dragos Foianu (2): ethtool: fixed trailing statements in ethtool net/irda: fixed style issues in irlan_eth Eric Dumazet (3): ipv4: set transport header earlier vlan: mask vlan prio bits vlan: fix a race in egress prio management Fabio Estevam (2): ASoC: sglt5000: Fix the default value of CHIP_SSS_CTRL ASoC: sglt5000: Fix SGTL5000_PLL_FRAC_DIV_MASK Faidon Liambotis (1): MIPS: Octeon: Fix DT pruning bug with pip ports Florian Fainelli (1): MIPS: BMIPS: Fix thinko to release slave TP from reset Ganesan Ramalingam (1): MIPS: Netlogic: Fix USB block's coherent DMA mask Girish K S (1): spi: s3c64xx: add missing check for polling mode Greg Kroah-Hartman (7): sysfs.h: add __ATTR_RW() macro sysfs.h: add ATTRIBUTE_GROUPS() macro sysfs.h: add BIN_ATTR macro driver core: device.h: add RW and RO attribute macros sysfs: add support for binary attributes in groups driver core: add default groups to struct class staging: csr: remove driver Guenter Roeck (2): Partially revert "drm/i915: unconditionally use mt forcewake on hsw/ivb" driver core: Introduce device_create_groups H. Peter Anvin (1): x86, suspend: Handle CPUs which fail to #GP on RDMSR Haiyang Zhang (1): hyperv: Fix the NETIF_F_SG flag setting in netvsc Hauke Mehrtens (1): bgmac: add dependency to phylib Heiko Carstens (4): s390/bpf,jit: call module_free() from any context s390/bpf,jit: use generic jit dumper s390/bpf,jit: address randomize and write protect jit code s390/bpf,jit: add pkt_type support Imre Deak (1): drm/i915: fix lane bandwidth capping for DP 1.2 sinks Ingo Tuchscherer (1): s390/zcrypt: Alias for new zcrypt device driver base module J. Bruce Fields (1): nfsd4: fix minorversion support interface Jacek Anaszewski (1): iio: lps331ap: Fix wrong in_pressure_scale output value James Hogan (1): MIPS: KVM: Mark KVM_GUEST (T&E KVM) as BROKEN_ON_SMP Jan Beulich (1): xen-netfront: pull on receive skb may need to happen earlier Jan Kara (2): ext4: silence warning in ext4_writepages() ext4: fix warning in ext4_evict_inode() Jason Wang (4): macvtap: fix the missing ret value of TUNSETQUEUE macvtap: do not assume 802.1Q when send vlan packets tuntap: do not zerocopy if iov needs more pages than MAX_SKB_FRAGS macvtap: do not zerocopy if iov needs more pages than MAX_SKB_FRAGS Jayachandran C (1): MIPS: Netlogic: Add XLP PIC irqdomain Jerome Glisse (1): drm/radeon: use radeon device for request firmware Jonathan Cameron (1): iio:trigger: device_unregister->device_del to avoid double free Josef Bacik (3): Btrfs: update drop progress before stopping snapshot dropping Btrfs: fix lock leak when resuming snapshot deletion Btrfs: re-add root to dead root list if we stop dropping it Kees Cook (1): x86: Make sure IDT is page aligned Kuninori Morimoto (1): ASoC: wm8978: enable symmetric rates Lan Tianyu (1): ACPI / video: ignore BIOS initial backlight value for Fujitsu E753 Laurent Pinchart (2): drm/shmobile: Use the GEM PRIME helpers drm/rcar-du: Use the GEM PRIME helpers Linus Torvalds (1): Linux 3.11-rc2 Liu ShuoX (2): PM / Sleep: avoid 'autosleep' in shutdown progress PNP / ACPI: avoid garbage in resource name Maarten Lankhorst (1): drm/radeon: add missing ttm_eu_backoff_reservation to radeon_bo_list_validate Marc Zyngier (1): arm64: use common reboot infrastructure Marek Vasut (2): iio: mxs-lradc: Fix misuse of iio->trig iio: mxs-lradc: Remove useless check in read_raw Mark Brown (1): ASoC: wm8994: Remove overly noisy debug logging Markos Chandras (1): MIPS: kvm: Kconfig: Drop HAVE_KVM dependency from VIRTUALIZATION Matt Fleming (2): efivars: check for EFI_RUNTIME_SERVICES Revert "UEFI: Don't pass boot services regions to SetVirtualAddressMap()" Matthew Garrett (1): ACPI / video: Always call acpi_video_init_brightness() on init Michael Holzheu (2): s390/kdump: Disable mmap for s390 s390/kdump: Allow copy_oldmem_page() copy to virtual memory Michael Mueller (1): s390/ptrace: PTRACE_TE_ABORT_RAND Michal Simek (1): spi/xilinx: Revert master->setup function removal Neil Horman (1): atl1e: unmap partially mapped skb on dma error and free skb NeilBrown (3): md/raid10: fix two problems with RAID10 resync. md: Remove recent change which allows devices to skip recovery. md/raid1: fix bio handling problems in process_checks() Oliver Schinagl (3): sysfs: prevent warning when only using binary attributes sysfs: add more helper macro's for (bin_)attribute(_groups) sysfs: use file mode defines from stat.h Padmavathi Venna (1): ASoC: Samsung: Set RFS and BFS in slave mode Paolo Valente (1): pkt_sched: sch_qfq: remove a source of high packet delay/jitter Paul Bolle (2): cpufreq: s3c24xx: rename CONFIG_CPU_FREQ_S3C24XX_DEBUGFS cpufreq: s3c24xx: fix "depends on ARM_S3C24XX" in Kconfig Paul Gortmaker (28): alpha: delete __cpuinit usage from all users parisc: delete __cpuinit usage from all users MIPS: Delete __cpuinit/__CPUINIT usage from MIPS code arm: delete __cpuinit/__CPUINIT usage from all ARM users sparc: delete __cpuinit/__CPUINIT usage from all users arm64: delete __cpuinit usage from all users blackfin: delete __cpuinit usage from all blackfin files s390: delete __cpuinit usage from all s390 files sh: delete __cpuinit usage from all sh files tile: delete __cpuinit usage from all tile files metag: delete __cpuinit usage from all metag files cris: delete __cpuinit usage from all cris files frv: delete __cpuinit usage from all frv files hexagon: delete __cpuinit usage from all hexagon files m32r: delete __cpuinit usage from all m32r files openrisc: delete __cpuinit usage from all openrisc files xtensa: delete __cpuinit usage from all xtensa files score: delete __cpuinit usage from all score files x86: delete __cpuinit usage from all x86 files clocksource+irqchip: delete __cpuinit usage from all related files cpufreq: delete __cpuinit usage from all cpufreq files hwmon: delete __cpuinit usage from all hwmon files acpi: delete __cpuinit usage from all acpi files net: delete __cpuinit usage from all net files rcu: delete __cpuinit usage from all rcu files kernel: delete __cpuinit usage from all core kernel files drivers: delete __cpuinit usage from all remaining drivers files block: delete __cpuinit usage from all block files Paulo Zanoni (1): drm/i915: switch disable_power_well default value to 1 Peng Tao (1): vfs: constify dentry parameter in d_count() Peter Meerwald (1): iio staging: fix lis3l02dq, read error handling Peter Ujfalusi (4): ASoC: omap-pcm: Request the DMA channel differently when DT is involved ASoC: omap-mcpdm: Do not use platform_get_resource_byname() for DMA ASoC: omap-dmic: Do not use platform_get_resource_byname() for DMA ASoC: omap-mcbsp: Use different method for DMA request when booted with DT Rafael J. Wysocki (3): ACPI / scan: Do not try to attach scan handlers to devices having them ACPI / scan: Always call acpi_bus_scan() for bus check notifications ACPI / video / i915: No ACPI backlight if firmware expects Windows 8 Ralf Baechle (1): MIPS: Delete dead invocation of exception_exit(). Randy Dunlap (1): driver-core: fix new kernel-doc warning in base/platform.c Richard Weinberger (5): um: Fix return value of strnlen_user() um: Mark stub pages mapping with VM_PFNMAP um: Fix wait_stub_done() error handling um: siginfo cleanup um: remove dead code Sachin Kamat (1): hwmon: (abx500) Staticize abx500_temp_attributes Sarveshwar Bandi (1): be2net: Fix to avoid hardware workaround when not needed Sebastian Ott (1): s390/qdio: remove unused variable Sergey Senozhatsky (1): radeon kms: do not flush uninitialized hotplug work Srivatsa S. Bhat (2): cpufreq: Revert commit a66b2e to fix suspend/resume regression cpufreq: Revert commit 2f7021a8 to fix CPU hotplug regression Stefan Behrens (1): Btrfs: fix wrong write offset when replacing a device Stephen Warren (1): spi: revert master->setup function removal for altera and nuc900 Steven Miao (1): smp: blackfin: fix check error, using atomic_ops to handle atomic_t type Sylvain 'ythier' Hitier (1): uvesafb: Really allow mtrr being 0, as documented and warn()ed Takashi Iwai (13): sound: oss/vwsnd: Add missing inclusion of linux/delay.h sound: oss/vwsnd: Always define vwsnd_mutex ALSA: asihpi: Fix unlocked snd_pcm_stop() call ALSA: atiixp: Fix unlocked snd_pcm_stop() call ALSA: 6fire: Fix unlocked snd_pcm_stop() call ALSA: ua101: Fix unlocked snd_pcm_stop() call ALSA: usx2y: Fix unlocked snd_pcm_stop() call ALSA: pxa2xx: Fix unlocked snd_pcm_stop() call ASoC: atmel: Fix unlocked snd_pcm_stop() call ASoC: s6000: Fix unlocked snd_pcm_stop() call [media] saa7134: Fix unlocked snd_pcm_stop() call staging: line6: Fix unlocked snd_pcm_stop() call ALSA: seq-oss: Initialize MIDI clients asynchronously Theodore Ts'o (9): ext4: fix ext4_get_group_number() ext4: don't show usrquota/grpquota twice in /proc/mounts ext4: fix spelling errors and a comment in extent_status tree ext4: don't allow ext4_free_blocks() to fail due to ENOMEM ext4: fix error handling in ext4_ext_truncate() ext4: simplify calculation of blocks to free on error ext4: make the extent_status code more robust against ENOMEM failures ext4: yield during large unlinks ext4: call ext4_es_lru_add() after handling cache miss Tim Gardner (1): mlx5 core: Fix __udivdi3 when compiling for 32 bit arches Tony Wu (1): MIPS: tlbex: Fix typo in r3000 tlb store handler Toshi Kani (1): ACPI / memhotplug: Fix a stale pointer in error path Tristan Schmelcher (1): uml: Fix which_tmpdir failure when /dev/shm is a symlink, and in other edge cases Trond Myklebust (2): SUNRPC: Fix another issue with rpc_client_register() NFSv4: Fix a regression against the FreeBSD server Wei Yongjun (3): iio: dac: ad7303: fix error return code in ad7303_probe() iio: ti_am335x_adc: add missing .driver_module to struct iio_info staging:iio:ad7291: add missing .driver_module to struct iio_info Will Deacon (1): arm64: mm: don't treat user cache maintenance faults as writes Xiao Guangrong (1): KVM: MMU: avoid fast page fault fixing mmio page fault Xiong Zhang (1): drm/i915: Correct obj->mm_list link to dev_priv->dev_priv->mm.inactive_list Xiong Zhou (1): x86/platform/ce4100: Add header file for reboot type Zheng Liu (2): ext4: fix a BUG when opening a file with O_TMPFILE flag ext3: fix a BUG when opening a file with O_TMPFILE flag stephen hemminger (1): vxlan: add necessary locking on device removal ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 2013-07-21 19:53 Linux 3.11-rc2 Linus Torvalds @ 2013-07-21 21:07 ` Tobias Klausmann 2013-07-22 13:08 ` Rafael J. Wysocki 2013-07-21 23:08 ` James Hogan ` (2 subsequent siblings) 3 siblings, 1 reply; 71+ messages in thread From: Tobias Klausmann @ 2013-07-21 21:07 UTC (permalink / raw) To: Linus Torvalds, Linux Kernel Mailing List On 21.07.2013 21:53, Linus Torvalds wrote: > So it's been another week, and -rc2 is out there. ... > > (b) we had a late change to how ACPI backlight handling is done on > certain machines, and while this kind of thing really shouldn't be > done outside the merge window, I ended up pulling it anyway. But I'd > *really* like to have people test this thing particularly on laptops > with intel-based graphics. It should only matter (and hopefully > improve things) for the newer ones with BIOSes designed for Windows 8, > but hey, the more testing, the better. Backlight handling has been > painful before, so I'm mentioning this explicitly. > This pach finally fixes my backlight control! Thanks! Tobias Klausmann ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 2013-07-21 21:07 ` Tobias Klausmann @ 2013-07-22 13:08 ` Rafael J. Wysocki 2013-07-22 15:43 ` Tobias Klausmann 0 siblings, 1 reply; 71+ messages in thread From: Rafael J. Wysocki @ 2013-07-22 13:08 UTC (permalink / raw) To: Tobias Klausmann Cc: Linus Torvalds, Linux Kernel Mailing List, ACPI Devel Maling List On Sunday, July 21, 2013 11:07:03 PM Tobias Klausmann wrote: > On 21.07.2013 21:53, Linus Torvalds wrote: > > So it's been another week, and -rc2 is out there. > ... > > > > (b) we had a late change to how ACPI backlight handling is done on > > certain machines, and while this kind of thing really shouldn't be > > done outside the merge window, I ended up pulling it anyway. But I'd > > *really* like to have people test this thing particularly on laptops > > with intel-based graphics. It should only matter (and hopefully > > improve things) for the newer ones with BIOSes designed for Windows 8, > > but hey, the more testing, the better. Backlight handling has been > > painful before, so I'm mentioning this explicitly. > > > > This pach finally fixes my backlight control! Yes, it fixes that for a number of people, which is the reason why I send the pull request in the first place, but it also turns out to break things for some people and therefore it'll have to be reverted. We're still going to work on that, though. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 2013-07-22 13:08 ` Rafael J. Wysocki @ 2013-07-22 15:43 ` Tobias Klausmann 0 siblings, 0 replies; 71+ messages in thread From: Tobias Klausmann @ 2013-07-22 15:43 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, ACPI Devel Maling List On 22.07.2013 15:08, Rafael J. Wysocki wrote: > On Sunday, July 21, 2013 11:07:03 PM Tobias Klausmann wrote: >> On 21.07.2013 21:53, Linus Torvalds wrote: >>> So it's been another week, and -rc2 is out there. >> ... >>> (b) we had a late change to how ACPI backlight handling is done on >>> certain machines, and while this kind of thing really shouldn't be >>> done outside the merge window, I ended up pulling it anyway. But I'd >>> *really* like to have people test this thing particularly on laptops >>> with intel-based graphics. It should only matter (and hopefully >>> improve things) for the newer ones with BIOSes designed for Windows 8, >>> but hey, the more testing, the better. Backlight handling has been >>> painful before, so I'm mentioning this explicitly. >>> >> This pach finally fixes my backlight control! > Yes, it fixes that for a number of people, which is the reason why I send > the pull request in the first place, but it also turns out to break things > for some people and therefore it'll have to be reverted. > > We're still going to work on that, though. > > Thanks, > Rafael > > If you have new patches ready for this and you want them to be tested, let me know! Thanks, Tobias ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 2013-07-21 19:53 Linux 3.11-rc2 Linus Torvalds 2013-07-21 21:07 ` Tobias Klausmann @ 2013-07-21 23:08 ` James Hogan 2013-07-22 13:02 ` Rafael J. Wysocki 2013-07-22 1:25 ` Dave Chinner 2013-07-23 1:04 ` rydberg 3 siblings, 1 reply; 71+ messages in thread From: James Hogan @ 2013-07-21 23:08 UTC (permalink / raw) To: Linus Torvalds Cc: Linux Kernel Mailing List, Kamal Mostafa, Matthew Garrett, Rafael J. Wysocki On 21 July 2013 20:53, Linus Torvalds <torvalds@linux-foundation.org> wrote: > (b) we had a late change to how ACPI backlight handling is done on > certain machines, and while this kind of thing really shouldn't be > done outside the merge window, I ended up pulling it anyway. But I'd > *really* like to have people test this thing particularly on laptops > with intel-based graphics. It should only matter (and hopefully > improve things) for the newer ones with BIOSes designed for Windows 8, > but hey, the more testing, the better. Backlight handling has beenin > painful before, so I'm mentioning this explicitly. 8c5bd7a "ACPI / video / i915: No ACPI backlight if firmware expects Windows 8" breaks backlight control for me because /sys/class/backlight/acpi_video0 disappears, and /sys/class/backlight/intel_backlight doesn't seem to have any effect. Note that acpi_video0 only worked because I was applying "[PATCH] drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight" [1], so strictly speaking mainline already didn't work. Cheers James [1] http://lkml.org/lkml/2013/7/19/748 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 2013-07-21 23:08 ` James Hogan @ 2013-07-22 13:02 ` Rafael J. Wysocki 2013-07-22 13:15 ` Martin Steigerwald ` (3 more replies) 0 siblings, 4 replies; 71+ messages in thread From: Rafael J. Wysocki @ 2013-07-22 13:02 UTC (permalink / raw) To: James Hogan, Linus Torvalds Cc: Linux Kernel Mailing List, Kamal Mostafa, Matthew Garrett, Rafael J. Wysocki, Steven Newbury On Monday, July 22, 2013 12:08:40 AM James Hogan wrote: > On 21 July 2013 20:53, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > (b) we had a late change to how ACPI backlight handling is done on > > certain machines, and while this kind of thing really shouldn't be > > done outside the merge window, I ended up pulling it anyway. But I'd > > *really* like to have people test this thing particularly on laptops > > with intel-based graphics. It should only matter (and hopefully > > improve things) for the newer ones with BIOSes designed for Windows 8, > > but hey, the more testing, the better. Backlight handling has beenin > > painful before, so I'm mentioning this explicitly. > > 8c5bd7a "ACPI / video / i915: No ACPI backlight if firmware expects > Windows 8" breaks backlight control for me because > /sys/class/backlight/acpi_video0 disappears, and > /sys/class/backlight/intel_backlight doesn't seem to have any effect. > > Note that acpi_video0 only worked because I was applying "[PATCH] > drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight" [1], so > strictly speaking mainline already didn't work. James, sorry for breaking things for you. The patch you're mentioning is going to hit the mainline at one point anyway I suppose. In the meantime I received a report from Steven Newbury that these changes broke things for him too, so we need to revert commits 8c5bd7a and efaa14c. The other two commits in the series should be benign. Linus, do you want me to send a pull request reverting 8c5bd7a and efaa14c? Rafael (who's having a particularly bad day today) ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 2013-07-22 13:02 ` Rafael J. Wysocki @ 2013-07-22 13:15 ` Martin Steigerwald 2013-07-22 13:37 ` Rafael J. Wysocki 2013-07-22 13:21 ` James Hogan ` (2 subsequent siblings) 3 siblings, 1 reply; 71+ messages in thread From: Martin Steigerwald @ 2013-07-22 13:15 UTC (permalink / raw) To: Rafael J. Wysocki Cc: James Hogan, Linus Torvalds, Linux Kernel Mailing List, Kamal Mostafa, Matthew Garrett, Rafael J. Wysocki, Steven Newbury Am Montag, 22. Juli 2013, 15:02:22 schrieb Rafael J. Wysocki: > On Monday, July 22, 2013 12:08:40 AM James Hogan wrote: > > On 21 July 2013 20:53, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > > (b) we had a late change to how ACPI backlight handling is done on > > > > > > certain machines, and while this kind of thing really shouldn't be > > > done outside the merge window, I ended up pulling it anyway. But I'd > > > *really* like to have people test this thing particularly on laptops > > > with intel-based graphics. It should only matter (and hopefully > > > improve things) for the newer ones with BIOSes designed for Windows 8, > > > but hey, the more testing, the better. Backlight handling has beenin > > > painful before, so I'm mentioning this explicitly. > > > > 8c5bd7a "ACPI / video / i915: No ACPI backlight if firmware expects > > Windows 8" breaks backlight control for me because > > /sys/class/backlight/acpi_video0 disappears, and > > /sys/class/backlight/intel_backlight doesn't seem to have any effect. > > > > Note that acpi_video0 only worked because I was applying "[PATCH] > > drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight" [1], so > > strictly speaking mainline already didn't work. > > James, sorry for breaking things for you. The patch you're mentioning is > going to hit the mainline at one point anyway I suppose. Dunno whether thats related, but after locking screen today and screen blanker kicking in (just a blank screen), I was not able to reactivate the display again by typing a key or so unless I closed the laptop display lid, let the machine suspend (to ram) and opened it again. Plain 3.11-rc2 on ThinkPad T520: martin@merkaba:~> phoronix-test-suite system-info Phoronix Test Suite v4.6.0 System Information Hardware: Processor: Intel Core i5-2520M @ 3.20GHz (4 Cores), Motherboard: LENOVO 42433WG, Chipset: Intel 2nd Generation Core Family DRAM, Memory: 8192MB, Disk: 300GB INTEL SSDSA2CW30 + 30GB INTEL SSDMCEAC03, Graphics: Intel 2nd Generation Core Family IGP, Audio: Conexant CX20590, Network: Intel 82579LM Gigabit Connection + Intel Centrino Advanced-N 6205 Software: OS: Debian unstable, Kernel: 3.11.0-rc2-tp520 (x86_64), Desktop: KDE 4.10.5, Display Server: X Server 1.12.4, Display Driver: intel 2.20.14, OpenGL: 3.0 Mesa 9.1.4, Compiler: GCC 4.8, File-System: btrfs, Screen Resolution: 1920x1080 Thanks, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 2013-07-22 13:15 ` Martin Steigerwald @ 2013-07-22 13:37 ` Rafael J. Wysocki 2013-07-22 18:46 ` Martin Steigerwald 2013-07-24 5:10 ` Kalle Valo 0 siblings, 2 replies; 71+ messages in thread From: Rafael J. Wysocki @ 2013-07-22 13:37 UTC (permalink / raw) To: Martin Steigerwald Cc: James Hogan, Linus Torvalds, Linux Kernel Mailing List, Kamal Mostafa, Matthew Garrett, Rafael J. Wysocki, Steven Newbury On Monday, July 22, 2013 03:15:38 PM Martin Steigerwald wrote: > Am Montag, 22. Juli 2013, 15:02:22 schrieb Rafael J. Wysocki: > > On Monday, July 22, 2013 12:08:40 AM James Hogan wrote: > > > On 21 July 2013 20:53, Linus Torvalds <torvalds@linux-foundation.org> > wrote: > > > > (b) we had a late change to how ACPI backlight handling is done on > > > > > > > > certain machines, and while this kind of thing really shouldn't be > > > > done outside the merge window, I ended up pulling it anyway. But I'd > > > > *really* like to have people test this thing particularly on laptops > > > > with intel-based graphics. It should only matter (and hopefully > > > > improve things) for the newer ones with BIOSes designed for Windows 8, > > > > but hey, the more testing, the better. Backlight handling has beenin > > > > painful before, so I'm mentioning this explicitly. > > > > > > 8c5bd7a "ACPI / video / i915: No ACPI backlight if firmware expects > > > Windows 8" breaks backlight control for me because > > > /sys/class/backlight/acpi_video0 disappears, and > > > /sys/class/backlight/intel_backlight doesn't seem to have any effect. > > > > > > Note that acpi_video0 only worked because I was applying "[PATCH] > > > drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight" [1], so > > > strictly speaking mainline already didn't work. > > > > James, sorry for breaking things for you. The patch you're mentioning is > > going to hit the mainline at one point anyway I suppose. > > Dunno whether thats related, but after locking screen today and screen blanker > kicking in (just a blank screen), I was not able to reactivate the display > again by typing a key or so unless I closed the laptop display lid, let the > machine suspend (to ram) and opened it again. > > Plain 3.11-rc2 on ThinkPad T520: Well, please try to revert commits efaa14c and 8c5bd7a (in this order) and see if that helps. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 2013-07-22 13:37 ` Rafael J. Wysocki @ 2013-07-22 18:46 ` Martin Steigerwald 2013-07-22 19:57 ` Rafael J. Wysocki 2013-07-24 5:10 ` Kalle Valo 1 sibling, 1 reply; 71+ messages in thread From: Martin Steigerwald @ 2013-07-22 18:46 UTC (permalink / raw) To: Rafael J. Wysocki Cc: James Hogan, Linus Torvalds, Linux Kernel Mailing List, Kamal Mostafa, Matthew Garrett, Rafael J. Wysocki, Steven Newbury Am Montag, 22. Juli 2013, 15:37:42 schrieb Rafael J. Wysocki: > On Monday, July 22, 2013 03:15:38 PM Martin Steigerwald wrote: > > Am Montag, 22. Juli 2013, 15:02:22 schrieb Rafael J. Wysocki: > > > On Monday, July 22, 2013 12:08:40 AM James Hogan wrote: > > > > On 21 July 2013 20:53, Linus Torvalds <torvalds@linux-foundation.org> > > > > wrote: > > > > > (b) we had a late change to how ACPI backlight handling is done on > > > > > > > > > > certain machines, and while this kind of thing really shouldn't be > > > > > done outside the merge window, I ended up pulling it anyway. But I'd > > > > > *really* like to have people test this thing particularly on laptops > > > > > with intel-based graphics. It should only matter (and hopefully > > > > > improve things) for the newer ones with BIOSes designed for Windows > > > > > 8, > > > > > but hey, the more testing, the better. Backlight handling has beenin > > > > > painful before, so I'm mentioning this explicitly. > > > > > > > > 8c5bd7a "ACPI / video / i915: No ACPI backlight if firmware expects > > > > Windows 8" breaks backlight control for me because > > > > /sys/class/backlight/acpi_video0 disappears, and > > > > /sys/class/backlight/intel_backlight doesn't seem to have any effect. > > > > > > > > Note that acpi_video0 only worked because I was applying "[PATCH] > > > > drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight" [1], so > > > > strictly speaking mainline already didn't work. > > > > > > James, sorry for breaking things for you. The patch you're mentioning > > > is > > > going to hit the mainline at one point anyway I suppose. > > > > Dunno whether thats related, but after locking screen today and screen > > blanker kicking in (just a blank screen), I was not able to reactivate > > the display again by typing a key or so unless I closed the laptop > > display lid, let the machine suspend (to ram) and opened it again. > > > Plain 3.11-rc2 on ThinkPad T520: > Well, please try to revert commits efaa14c and 8c5bd7a (in this order) and > see if that helps. Okay. Done that. It does help. Thanks, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 2013-07-22 18:46 ` Martin Steigerwald @ 2013-07-22 19:57 ` Rafael J. Wysocki 0 siblings, 0 replies; 71+ messages in thread From: Rafael J. Wysocki @ 2013-07-22 19:57 UTC (permalink / raw) To: Martin Steigerwald Cc: James Hogan, Linus Torvalds, Linux Kernel Mailing List, Kamal Mostafa, Matthew Garrett, Rafael J. Wysocki, Steven Newbury On Monday, July 22, 2013 08:46:47 PM Martin Steigerwald wrote: > Am Montag, 22. Juli 2013, 15:37:42 schrieb Rafael J. Wysocki: > > On Monday, July 22, 2013 03:15:38 PM Martin Steigerwald wrote: > > > Am Montag, 22. Juli 2013, 15:02:22 schrieb Rafael J. Wysocki: > > > > On Monday, July 22, 2013 12:08:40 AM James Hogan wrote: > > > > > On 21 July 2013 20:53, Linus Torvalds <torvalds@linux-foundation.org> > > > > > > wrote: > > > > > > (b) we had a late change to how ACPI backlight handling is done on > > > > > > > > > > > > certain machines, and while this kind of thing really shouldn't be > > > > > > done outside the merge window, I ended up pulling it anyway. But I'd > > > > > > *really* like to have people test this thing particularly on laptops > > > > > > with intel-based graphics. It should only matter (and hopefully > > > > > > improve things) for the newer ones with BIOSes designed for Windows > > > > > > 8, > > > > > > but hey, the more testing, the better. Backlight handling has beenin > > > > > > painful before, so I'm mentioning this explicitly. > > > > > > > > > > 8c5bd7a "ACPI / video / i915: No ACPI backlight if firmware expects > > > > > Windows 8" breaks backlight control for me because > > > > > /sys/class/backlight/acpi_video0 disappears, and > > > > > /sys/class/backlight/intel_backlight doesn't seem to have any effect. > > > > > > > > > > Note that acpi_video0 only worked because I was applying "[PATCH] > > > > > drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight" [1], so > > > > > strictly speaking mainline already didn't work. > > > > > > > > James, sorry for breaking things for you. The patch you're mentioning > > > > is > > > > going to hit the mainline at one point anyway I suppose. > > > > > > Dunno whether thats related, but after locking screen today and screen > > > blanker kicking in (just a blank screen), I was not able to reactivate > > > the display again by typing a key or so unless I closed the laptop > > > display lid, let the machine suspend (to ram) and opened it again. > > > > > Plain 3.11-rc2 on ThinkPad T520: > > Well, please try to revert commits efaa14c and 8c5bd7a (in this order) and > > see if that helps. > > Okay. Done that. It does help. OK, thanks! Rafael ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 2013-07-22 13:37 ` Rafael J. Wysocki 2013-07-22 18:46 ` Martin Steigerwald @ 2013-07-24 5:10 ` Kalle Valo 1 sibling, 0 replies; 71+ messages in thread From: Kalle Valo @ 2013-07-24 5:10 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Martin Steigerwald, James Hogan, Linus Torvalds, Linux Kernel Mailing List, Kamal Mostafa, Matthew Garrett, Rafael J. Wysocki, Steven Newbury "Rafael J. Wysocki" <rjw@sisk.pl> writes: > Well, please try to revert commits efaa14c and 8c5bd7a (in this order) and see > if that helps. On 3.11-rc2-wl (from wireless-testing.git) my Thinkpad X230 display went really dark every time during resume and I had to blindly write to sysfs to be able to see anything. With 3.10-wl I didn't see this. Reverting the commits above fixed the issue for me. I'm using Ubuntu 12.04 64 bit. More info about my laptop: thinkpad_acpi: ThinkPad ACPI Extras v0.24 thinkpad_acpi: http://ibm-acpi.sf.net/ thinkpad_acpi: ThinkPad BIOS G2ET82WW (2.02 ), EC unknown thinkpad_acpi: Lenovo ThinkPad X230, model 2324JB2 thinkpad_acpi: detected a 8-level brightness capable ThinkPad thinkpad_acpi: radio switch found; radios are enabled thinkpad_acpi: This ThinkPad has standard ACPI backlight brightness control, supported by the ACPI video driver thinkpad_acpi: Disabling thinkpad-acpi brightness events by default... thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked thinkpad_acpi: rfkill switch tpacpi_wwan_sw: radio is unblocked thinkpad_acpi: Standard ACPI backlight interface available, not loading native one thinkpad_acpi: Console audio control enabled, mode: monitor (read only) input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input5 -- Kalle Valo ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 2013-07-22 13:02 ` Rafael J. Wysocki 2013-07-22 13:15 ` Martin Steigerwald @ 2013-07-22 13:21 ` James Hogan 2013-07-22 18:11 ` Linus Torvalds 2013-07-22 18:16 ` Linux 3.11-rc2 Matthew Garrett 3 siblings, 0 replies; 71+ messages in thread From: James Hogan @ 2013-07-22 13:21 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linus Torvalds, Linux Kernel Mailing List, Kamal Mostafa, Matthew Garrett, Rafael J. Wysocki, Steven Newbury On 22 July 2013 14:02, Rafael J. Wysocki <rjw@sisk.pl> wrote: > On Monday, July 22, 2013 12:08:40 AM James Hogan wrote: >> On 21 July 2013 20:53, Linus Torvalds <torvalds@linux-foundation.org> wrote: >> > (b) we had a late change to how ACPI backlight handling is done on >> > certain machines, and while this kind of thing really shouldn't be >> > done outside the merge window, I ended up pulling it anyway. But I'd >> > *really* like to have people test this thing particularly on laptops >> > with intel-based graphics. It should only matter (and hopefully >> > improve things) for the newer ones with BIOSes designed for Windows 8, >> > but hey, the more testing, the better. Backlight handling has beenin >> > painful before, so I'm mentioning this explicitly. >> >> 8c5bd7a "ACPI / video / i915: No ACPI backlight if firmware expects >> Windows 8" breaks backlight control for me because >> /sys/class/backlight/acpi_video0 disappears, and >> /sys/class/backlight/intel_backlight doesn't seem to have any effect. >> >> Note that acpi_video0 only worked because I was applying "[PATCH] >> drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight" [1], so >> strictly speaking mainline already didn't work. > > James, sorry for breaking things for you. The patch you're mentioning is going > to hit the mainline at one point anyway I suppose. > > In the meantime I received a report from Steven Newbury that these changes > broke things for him too, so we need to revert commits 8c5bd7a and efaa14c. > The other two commits in the series should be benign. Feel free to Cc me on updated versions of the patches if you'd like me to test. Cheers James ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 2013-07-22 13:02 ` Rafael J. Wysocki 2013-07-22 13:15 ` Martin Steigerwald 2013-07-22 13:21 ` James Hogan @ 2013-07-22 18:11 ` Linus Torvalds 2013-07-22 19:54 ` Rafael J. Wysocki 2013-07-22 18:16 ` Linux 3.11-rc2 Matthew Garrett 3 siblings, 1 reply; 71+ messages in thread From: Linus Torvalds @ 2013-07-22 18:11 UTC (permalink / raw) To: Rafael J. Wysocki Cc: James Hogan, Linux Kernel Mailing List, Kamal Mostafa, Matthew Garrett, Rafael J. Wysocki, Steven Newbury On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > Linus, do you want me to send a pull request reverting 8c5bd7a and efaa14c? Yes, but let's wait a while. Not because I think we'll fix the problem (hey, miracles might happen), but because I think it would be useful to couple the reverts with information about the particular machines that broke (and the people who reported it). So that when we inevitably try again, we can perhaps get some testing effort with those machines/people. It doesn't seem to be a show-stopped for a large number of people, so there's no huge hurry. I'd suggest doing the revert just in time for rc3, but waiting until then to gather info about people who see breakage. Sound like a plan? Linus ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 2013-07-22 18:11 ` Linus Torvalds @ 2013-07-22 19:54 ` Rafael J. Wysocki 2013-07-23 18:46 ` Linux 3.11-rc2 (acpi backlight) Kamal Mostafa 2013-07-25 13:00 ` Rafael J. Wysocki 0 siblings, 2 replies; 71+ messages in thread From: Rafael J. Wysocki @ 2013-07-22 19:54 UTC (permalink / raw) To: Linus Torvalds Cc: James Hogan, Linux Kernel Mailing List, Kamal Mostafa, Matthew Garrett, Rafael J. Wysocki, Steven Newbury, ACPI Devel Maling List On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote: > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > > > Linus, do you want me to send a pull request reverting 8c5bd7a and efaa14c? > > Yes, but let's wait a while. Not because I think we'll fix the problem > (hey, miracles might happen), but because I think it would be useful > to couple the reverts with information about the particular machines > that broke (and the people who reported it). So that when we > inevitably try again, we can perhaps get some testing effort with > those machines/people. > > It doesn't seem to be a show-stopped for a large number of people, so > there's no huge hurry. I'd suggest doing the revert just in time for > rc3, but waiting until then to gather info about people who see > breakage. > > Sound like a plan? Yes, it does. Rafael ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight) 2013-07-22 19:54 ` Rafael J. Wysocki @ 2013-07-23 18:46 ` Kamal Mostafa 2013-07-24 0:05 ` Rafael J. Wysocki 2013-07-25 13:00 ` Rafael J. Wysocki 1 sibling, 1 reply; 71+ messages in thread From: Kamal Mostafa @ 2013-07-23 18:46 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linus Torvalds, James Hogan, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, Steven Newbury, ACPI Devel Maling List [-- Attachment #1: Type: text/plain, Size: 1204 bytes --] On Mon, 2013-07-22 at 21:54 +0200, Rafael J. Wysocki wrote: > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote: > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > > > > > Linus, do you want me to send a pull request reverting 8c5bd7a and efaa14c? > > > > Yes, but [...] I'd suggest doing the revert just in time for > > rc3, but waiting until then to gather info about people who see > > breakage. > > > > Sound like a plan? > > Yes, it does. > > Rafael Hi Rafael- For your reference... As James Hogan reported, those ACPI changes break backlight control on the "Dell XPS13" Ivy Bridge models (the Sandy Bridge XPS13 model is not affected). I confirm that reverting 8c5bd7a and efaa14c fixes it again. Also FYI... On Mon, 2013-07-22 at 00:08 +0100, James Hogan wrote: > Note that acpi_video0 only worked because I was applying "[PATCH] > drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight" [1], so > strictly speaking mainline already didn't work. > [1] http://lkml.org/lkml/2013/7/19/748 That patch is now queued up in drm-intel/drm-intel-fixes, so should be making its way to mainline soon. -Kamal [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight) 2013-07-23 18:46 ` Linux 3.11-rc2 (acpi backlight) Kamal Mostafa @ 2013-07-24 0:05 ` Rafael J. Wysocki 2013-07-24 4:54 ` Steven Newbury ` (2 more replies) 0 siblings, 3 replies; 71+ messages in thread From: Rafael J. Wysocki @ 2013-07-24 0:05 UTC (permalink / raw) To: Kamal Mostafa, James Hogan, Steven Newbury, Martin Steigerwald, Jörg Otte Cc: Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, ACPI Devel Maling List On Tuesday, July 23, 2013 11:46:29 AM Kamal Mostafa wrote: > On Mon, 2013-07-22 at 21:54 +0200, Rafael J. Wysocki wrote: > > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote: > > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > > > > > > > Linus, do you want me to send a pull request reverting 8c5bd7a and efaa14c? > > > > > > Yes, but [...] I'd suggest doing the revert just in time for > > > rc3, but waiting until then to gather info about people who see > > > breakage. > > > > > > Sound like a plan? > > > > Yes, it does. > > > > Rafael > > > Hi Rafael- > > For your reference... > > As James Hogan reported, those ACPI changes break backlight control on > the "Dell XPS13" Ivy Bridge models (the Sandy Bridge XPS13 model is not > affected). > > I confirm that reverting 8c5bd7a and efaa14c fixes it again. Thanks! I'd like to collect some information on the systems having problems with those two commits (to see if they are similar somehow). It seems that one common symptom is that brightness cannot be controlled through function keys. Is that correct for all of you? If so, did you try any other way to control brightness, like a GUI-based? Also, can you all please send me (a) the output of dmidecode and (b) the contents of /proc/cpuinfo from your systems? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight) 2013-07-24 0:05 ` Rafael J. Wysocki @ 2013-07-24 4:54 ` Steven Newbury 2013-07-24 6:49 ` James Hogan 2013-07-24 11:45 ` Jörg Otte 2 siblings, 0 replies; 71+ messages in thread From: Steven Newbury @ 2013-07-24 4:54 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Kamal Mostafa, James Hogan, Martin Steigerwald, Jörg Otte, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, ACPI Devel Maling List [-- Attachment #1: Type: text/plain, Size: 1491 bytes --] On Wed, 2013-07-24 at 02:05 +0200, Rafael J. Wysocki wrote: > On Tuesday, July 23, 2013 11:46:29 AM Kamal Mostafa wrote: > > On Mon, 2013-07-22 at 21:54 +0200, Rafael J. Wysocki wrote: > > > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote: > > > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > > > > > > > > > Linus, do you want me to send a pull request reverting 8c5bd7a and efaa14c? > > > > > > > > Yes, but [...] I'd suggest doing the revert just in time for > > > > rc3, but waiting until then to gather info about people who see > > > > breakage. > > > > > > > > Sound like a plan? > > > > > > Yes, it does. > > > > > > Rafael > > > > > > Hi Rafael- > > > > For your reference... > > > > As James Hogan reported, those ACPI changes break backlight control on > > the "Dell XPS13" Ivy Bridge models (the Sandy Bridge XPS13 model is not > > affected). > > > > I confirm that reverting 8c5bd7a and efaa14c fixes it again. > > Thanks! > > I'd like to collect some information on the systems having problems with those > two commits (to see if they are similar somehow). > > It seems that one common symptom is that brightness cannot be controlled > through function keys. Is that correct for all of you? If so, did you try > any other way to control brightness, like a GUI-based? > > Also, can you all please send me (a) the output of dmidecode and (b) the > contents of /proc/cpuinfo from your systems? > > Rafael > > Attached. [-- Attachment #2: cpuinfo.txt --] [-- Type: text/plain, Size: 7664 bytes --] processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i7-3840QM CPU @ 2.80GHz stepping : 9 microcode : 0x15 cpu MHz : 2212.000 cache size : 8192 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 rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms bogomips : 5587.12 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i7-3840QM CPU @ 2.80GHz stepping : 9 microcode : 0x15 cpu MHz : 1960.000 cache size : 8192 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 rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms bogomips : 5587.12 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i7-3840QM CPU @ 2.80GHz stepping : 9 microcode : 0x15 cpu MHz : 2716.000 cache size : 8192 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 rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms bogomips : 5587.12 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i7-3840QM CPU @ 2.80GHz stepping : 9 microcode : 0x15 cpu MHz : 2072.000 cache size : 8192 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 rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms bogomips : 5587.12 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 4 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i7-3840QM CPU @ 2.80GHz stepping : 9 microcode : 0x15 cpu MHz : 1400.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 1 initial apicid : 1 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 rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms bogomips : 5587.12 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 5 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i7-3840QM CPU @ 2.80GHz stepping : 9 microcode : 0x15 cpu MHz : 1988.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 1 cpu cores : 4 apicid : 3 initial apicid : 3 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 rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms bogomips : 5587.12 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 6 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i7-3840QM CPU @ 2.80GHz stepping : 9 microcode : 0x15 cpu MHz : 2604.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 2 cpu cores : 4 apicid : 5 initial apicid : 5 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 rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms bogomips : 5587.12 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 7 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i7-3840QM CPU @ 2.80GHz stepping : 9 microcode : 0x15 cpu MHz : 2660.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 3 cpu cores : 4 apicid : 7 initial apicid : 7 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 rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms bogomips : 5587.12 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: [-- Attachment #3: dmi.txt --] [-- Type: text/plain, Size: 12816 bytes --] # dmidecode 2.11 SMBIOS 2.7 present. 40 structures occupying 2086 bytes. Table at 0x000EB190. Handle 0x0000, DMI type 0, 24 bytes BIOS Information Vendor: American Megatrends Inc. Version: 4.6.5 Release Date: 11/12/2012 Address: 0xF0000 Runtime Size: 64 kB ROM Size: 4096 kB Characteristics: PCI is supported BIOS is upgradeable BIOS shadowing is allowed Boot from CD is supported Selectable boot is supported EDD is supported Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Printer services are supported (int 17h) ACPI is supported USB legacy is supported BIOS boot specification is supported Targeted content distribution is supported UEFI is supported BIOS Revision: 4.6 Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: CLEVO CO. Product Name: W240EU/W250EUQ/W270EUQ Version: Not Applicable Serial Number: Not Applicable UUID: DFF59000-F04F-0000-0000-000000000000 Wake-up Type: Power Switch SKU Number: Not Applicable Family: Not Applicable Handle 0x0002, DMI type 2, 15 bytes Base Board Information Manufacturer: CLEVO CO. Product Name: W240EU/W250EUQ/W270EUQ Version: V3.0 Serial Number: Not Applicable Asset Tag: Tag 12345 Features: Board is a hosting board Board is replaceable Location In Chassis: Not Applicable Chassis Handle: 0x0003 Type: Motherboard Contained Object Handles: 0 Handle 0x0003, DMI type 3, 22 bytes Chassis Information Manufacturer: No Enclosure Type: Notebook Lock: Not Present Version: N/A Serial Number: None Asset Tag: No Asset Tag Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: None OEM Information: 0x000004D2 Height: Unspecified Number Of Power Cords: 1 Contained Elements: 0 SKU Number: To be filled by O.E.M. Handle 0x0004, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J_HDMI1 Internal Connector Type: None External Reference Designator: HDMI External Connector Type: Other Port Type: Video Port Handle 0x0005, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J_CRT1 Internal Connector Type: None External Reference Designator: CRT External Connector Type: Other Port Type: Video Port Handle 0x0006, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: AJ_MIC1 Internal Connector Type: None External Reference Designator: MIC In External Connector Type: Other Port Type: Audio Port Handle 0x0007, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: AJ_HP1 Internal Connector Type: None External Reference Designator: Headphone External Connector Type: Mini Jack (headphones) Port Type: Audio Port Handle 0x0008, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J_SPK1 Internal Connector Type: None External Reference Designator: Speaker Out External Connector Type: Other Port Type: Audio Port Handle 0x0009, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J_USB0 Internal Connector Type: None External Reference Designator: USB 2.0/3.0 External Connector Type: Access Bus (USB) Port Type: USB Handle 0x000A, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J_USB1 Internal Connector Type: None External Reference Designator: USB 2.0/3.0 External Connector Type: Access Bus (USB) Port Type: USB Handle 0x000B, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J_USB9 Internal Connector Type: None External Reference Designator: USB Port9 External Connector Type: Access Bus (USB) Port Type: USB Handle 0x000C, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J_RJ_1 Internal Connector Type: None External Reference Designator: Giga Lan External Connector Type: RJ-45 Port Type: Network Port Handle 0x000D, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J_CARD-REV1_1 Internal Connector Type: None External Reference Designator: Card Reader External Connector Type: Other Port Type: Other Handle 0x000E, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J_LCD1 - LVDS Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x000F, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J_LCD2 - LVDS Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x0010, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J_CCD1 - CCD Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x0011, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J_HDD1 - SATA HDD Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x0012, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J_ODD1 - SATA ODD Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x0013, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J_KB1 - Keyboard Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x0014, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J_KB2 - Keyboard Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x0015, DMI type 9, 17 bytes System Slot Information Designation: J_MINI1 Type: x1 PCI Express Current Usage: In Use Length: Short ID: 0 Characteristics: 3.3 V is provided Opening is shared PME signal is supported Bus Address: 0000:02:01.0 Handle 0x0016, DMI type 9, 17 bytes System Slot Information Designation: J3G1 Type: x1 PCI Express Current Usage: Available Length: Short ID: 1 Characteristics: 3.3 V is provided Opening is shared PME signal is supported Bus Address: 0000:ff:1c.3 Handle 0x0017, DMI type 10, 10 bytes On Board Device 1 Information Type: Video Status: Enabled Description: IGD On Board Device 2 Information Type: Ethernet Status: Enabled Description: RealTek RTL8411 On Board Device 3 Information Type: Sound Status: Enabled Description: VIA VT1802P Handle 0x0018, DMI type 11, 5 bytes OEM Strings String 1: 1558 String 2: OEM String String 3: To Be Filled By O.E.M. String 4: To Be Filled By O.E.M. String 5: BIOS:1.02.09 Handle 0x0019, DMI type 22, 26 bytes Portable Battery Location: Location of the battery Manufacturer: Battery Manufacturer Manufacture Date: 01/01/2007 Serial Number: Serial Number Name: BATT 1 Chemistry: Nickel Cadmium Design Capacity: 1020800 mWh Design Voltage: 11100 mV SBDS Version: 01.12.912 Maximum Error: Unknown OEM-specific Information: 0x12345678 Handle 0x001A, DMI type 32, 20 bytes System Boot Information Status: No errors detected Handle 0x001B, DMI type 7, 19 bytes Cache Information Socket Designation: CPU Internal L2 Configuration: Enabled, Not Socketed, Level 2 Operational Mode: Write Through Location: Internal Installed Size: 1024 kB Maximum Size: 1024 kB Supported SRAM Types: Unknown Installed SRAM Type: Unknown Speed: Unknown Error Correction Type: Multi-bit ECC System Type: Unified Associativity: 8-way Set-associative Handle 0x001C, DMI type 7, 19 bytes Cache Information Socket Designation: CPU Internal L1 Configuration: Enabled, Not Socketed, Level 1 Operational Mode: Write Through Location: Internal Installed Size: 256 kB Maximum Size: 256 kB Supported SRAM Types: Unknown Installed SRAM Type: Unknown Speed: Unknown Error Correction Type: Parity System Type: Data Associativity: 8-way Set-associative Handle 0x001D, DMI type 7, 19 bytes Cache Information Socket Designation: CPU Internal L3 Configuration: Enabled, Not Socketed, Level 3 Operational Mode: Write Back Location: Internal Installed Size: 8192 kB Maximum Size: 8192 kB Supported SRAM Types: Unknown Installed SRAM Type: Unknown Speed: Unknown Error Correction Type: Multi-bit ECC System Type: Unified Associativity: 16-way Set-associative Handle 0x001E, DMI type 16, 23 bytes Physical Memory Array Location: System Board Or Motherboard Use: System Memory Error Correction Type: None Maximum Capacity: 16 GB Error Information Handle: Not Provided Number Of Devices: 2 Handle 0x001F, DMI type 4, 42 bytes Processor Information Socket Designation: SOCKET 0 Type: Central Processor Family: Core i7 Manufacturer: Intel(R) Corporation ID: A9 06 03 00 FF FB EB BF Signature: Type 0, Family 6, Model 58, Stepping 9 Flags: FPU (Floating-point unit on-chip) VME (Virtual mode extension) DE (Debugging extension) PSE (Page size extension) TSC (Time stamp counter) MSR (Model specific registers) PAE (Physical address extension) MCE (Machine check exception) CX8 (CMPXCHG8 instruction supported) APIC (On-chip APIC hardware supported) SEP (Fast system call) MTRR (Memory type range registers) PGE (Page global enable) MCA (Machine check architecture) CMOV (Conditional move instruction supported) PAT (Page attribute table) PSE-36 (36-bit page size extension) CLFSH (CLFLUSH instruction supported) DS (Debug store) ACPI (ACPI supported) MMX (MMX technology supported) FXSR (FXSAVE and FXSTOR instructions supported) SSE (Streaming SIMD extensions) SSE2 (Streaming SIMD extensions 2) SS (Self-snoop) HTT (Multi-threading) TM (Thermal monitor supported) PBE (Pending break enabled) Version: Intel(R) Core(TM) i7-3840QM CPU @ 2.80GHz Voltage: 3.3 V External Clock: 100 MHz Max Speed: 3800 MHz Current Speed: 2800 MHz Status: Populated, Enabled Upgrade: <OUT OF SPEC> L1 Cache Handle: 0x001C L2 Cache Handle: 0x001B L3 Cache Handle: 0x001D Serial Number: Not Specified Asset Tag: Fill By OEM Part Number: Fill By OEM Core Count: 4 Core Enabled: 4 Thread Count: 8 Characteristics: 64-bit capable Handle 0x0020, DMI type 17, 34 bytes Memory Device Array Handle: 0x001E Error Information Handle: Not Provided Total Width: 64 bits Data Width: 64 bits Size: 4096 MB Form Factor: SODIMM Set: None Locator: ChannelA-DIMM0 Bank Locator: BANK 0 Type: DDR3 Type Detail: Synchronous Speed: 1600 MHz Manufacturer: Kingston Serial Number: C43E9D46 Asset Tag: 9876543210 Part Number: KHX1600C9S3/4GX Rank: 2 Configured Clock Speed: 1600 MHz Handle 0x0021, DMI type 20, 35 bytes Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000FFFFFFFF Range Size: 4 GB Physical Device Handle: 0x0020 Memory Array Mapped Address Handle: 0x0024 Partition Row Position: Unknown Interleave Position: 1 Interleaved Data Depth: 1 Handle 0x0022, DMI type 17, 34 bytes Memory Device Array Handle: 0x001E Error Information Handle: Not Provided Total Width: 64 bits Data Width: 64 bits Size: 4096 MB Form Factor: SODIMM Set: None Locator: ChannelB-DIMM0 Bank Locator: BANK 2 Type: DDR3 Type Detail: Synchronous Speed: 1600 MHz Manufacturer: Kingston Serial Number: C53E85C2 Asset Tag: 9876543210 Part Number: KHX1600C9S3/4GX Rank: 2 Configured Clock Speed: 1600 MHz Handle 0x0023, DMI type 20, 35 bytes Memory Device Mapped Address Starting Address: 0x00100000000 Ending Address: 0x001FFFFFFFF Range Size: 4 GB Physical Device Handle: 0x0022 Memory Array Mapped Address Handle: 0x0024 Partition Row Position: Unknown Interleave Position: 2 Interleaved Data Depth: 1 Handle 0x0024, DMI type 19, 31 bytes Memory Array Mapped Address Starting Address: 0x00000000000 Ending Address: 0x001FFFFFFFF Range Size: 8 GB Physical Array Handle: 0x001E Partition Width: 2 Handle 0x0027, DMI type 131, 64 bytes OEM-specific Type Header and Data: 83 40 27 00 35 00 00 00 00 00 00 00 00 00 00 00 F8 00 59 1E FF FF FF FF 01 00 00 00 01 00 08 00 E0 04 00 00 00 00 00 00 C8 00 FF FF 00 00 00 00 00 00 00 00 66 00 00 00 76 50 72 6F 00 00 00 00 Handle 0x0028, DMI type 13, 22 bytes BIOS Language Information Language Description Format: Long Installable Languages: 1 en|US|iso8859-1 Currently Installed Language: en|US|iso8859-1 Handle 0x002A, DMI type 127, 4 bytes End Of Table ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight) 2013-07-24 0:05 ` Rafael J. Wysocki 2013-07-24 4:54 ` Steven Newbury @ 2013-07-24 6:49 ` James Hogan 2013-07-24 7:14 ` Mike Galbraith 2013-07-24 7:19 ` Igor Gnatenko 2013-07-24 11:45 ` Jörg Otte 2 siblings, 2 replies; 71+ messages in thread From: James Hogan @ 2013-07-24 6:49 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Kamal Mostafa, Steven Newbury, Martin Steigerwald, Jörg Otte, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, ACPI Devel Maling List [-- Attachment #1: Type: text/plain, Size: 766 bytes --] On 24 July 2013 01:05, Rafael J. Wysocki <rjw@sisk.pl> wrote: > I'd like to collect some information on the systems having problems with those > two commits (to see if they are similar somehow). > > It seems that one common symptom is that brightness cannot be controlled > through function keys. Is that correct for all of you? If so, did you try > any other way to control brightness, like a GUI-based? For me both the Fn keys and the gui slider (kde) now control /sys/class/backlight/intel_backlight/brightness (which has no effect). Previously they both controlled the acpi one (that on -rc2 doesn't exist). > > Also, can you all please send me (a) the output of dmidecode and (b) the > contents of /proc/cpuinfo from your systems? attached -- James Hogan [-- Attachment #2: cpuinfo.txt --] [-- Type: text/plain, Size: 3812 bytes --] processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz stepping : 9 microcode : 0x17 cpu MHz : 2300.000 cache size : 4096 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 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 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 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms bogomips : 4988.23 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz stepping : 9 microcode : 0x17 cpu MHz : 1500.000 cache size : 4096 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid : 1 initial apicid : 1 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 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 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms bogomips : 4988.23 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz stepping : 9 microcode : 0x17 cpu MHz : 2375.000 cache size : 4096 KB physical id : 0 siblings : 4 core id : 1 cpu cores : 2 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 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 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms bogomips : 4988.23 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz stepping : 9 microcode : 0x17 cpu MHz : 2375.000 cache size : 4096 KB physical id : 0 siblings : 4 core id : 1 cpu cores : 2 apicid : 3 initial apicid : 3 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 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 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms bogomips : 4988.23 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: [-- Attachment #3: dmi.txt --] [-- Type: text/plain, Size: 20179 bytes --] # dmidecode 2.11 SMBIOS 2.7 present. 72 structures occupying 3078 bytes. Table at 0x000E1060. Handle 0x0004, DMI type 4, 42 bytes Processor Information Socket Designation: CPU Socket - U3E1 Type: Central Processor Family: Core i7 Manufacturer: Intel(R) Corporation ID: A9 06 03 00 FF FB EB BF Signature: Type 0, Family 6, Model 58, Stepping 9 Flags: FPU (Floating-point unit on-chip) VME (Virtual mode extension) DE (Debugging extension) PSE (Page size extension) TSC (Time stamp counter) MSR (Model specific registers) PAE (Physical address extension) MCE (Machine check exception) CX8 (CMPXCHG8 instruction supported) APIC (On-chip APIC hardware supported) SEP (Fast system call) MTRR (Memory type range registers) PGE (Page global enable) MCA (Machine check architecture) CMOV (Conditional move instruction supported) PAT (Page attribute table) PSE-36 (36-bit page size extension) CLFSH (CLFLUSH instruction supported) DS (Debug store) ACPI (ACPI supported) MMX (MMX technology supported) FXSR (FXSAVE and FXSTOR instructions supported) SSE (Streaming SIMD extensions) SSE2 (Streaming SIMD extensions 2) SS (Self-snoop) HTT (Multi-threading) TM (Thermal monitor supported) PBE (Pending break enabled) Version: Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz Voltage: 0.8 V External Clock: 100 MHz Max Speed: 2500 MHz Current Speed: 2500 MHz Status: Populated, Enabled Upgrade: <OUT OF SPEC> L1 Cache Handle: 0x0006 L2 Cache Handle: 0x0007 L3 Cache Handle: 0x0008 Serial Number: To Be Filled By O.E.M. Asset Tag: To Be Filled By O.E.M. Part Number: To Be Filled By O.E.M. Core Count: 2 Core Enabled: 2 Thread Count: 4 Characteristics: 64-bit capable Handle 0x0005, DMI type 7, 19 bytes Cache Information Socket Designation: L1-Cache Configuration: Enabled, Not Socketed, Level 1 Operational Mode: Write Through Location: Internal Installed Size: 32 kB Maximum Size: 32 kB Supported SRAM Types: Unknown Installed SRAM Type: Unknown Speed: Unknown Error Correction Type: Parity System Type: Data Associativity: 8-way Set-associative Handle 0x0006, DMI type 7, 19 bytes Cache Information Socket Designation: L1-Cache Configuration: Enabled, Not Socketed, Level 1 Operational Mode: Write Through Location: Internal Installed Size: 32 kB Maximum Size: 32 kB Supported SRAM Types: Unknown Installed SRAM Type: Unknown Speed: Unknown Error Correction Type: Parity System Type: Instruction Associativity: 8-way Set-associative Handle 0x0007, DMI type 7, 19 bytes Cache Information Socket Designation: L2-Cache Configuration: Enabled, Not Socketed, Level 2 Operational Mode: Write Through Location: Internal Installed Size: 256 kB Maximum Size: 256 kB Supported SRAM Types: Unknown Installed SRAM Type: Unknown Speed: Unknown Error Correction Type: Multi-bit ECC System Type: Unified Associativity: 8-way Set-associative Handle 0x0008, DMI type 7, 19 bytes Cache Information Socket Designation: L3-Cache Configuration: Enabled, Not Socketed, Level 3 Operational Mode: Write Back Location: Internal Installed Size: 4096 kB Maximum Size: 4096 kB Supported SRAM Types: Unknown Installed SRAM Type: Unknown Speed: Unknown Error Correction Type: Multi-bit ECC System Type: Unified Associativity: 16-way Set-associative Handle 0x0009, DMI type 129, 8 bytes OEM-specific Type Header and Data: 81 08 09 00 01 01 02 01 Strings: Intel_ASF Intel_ASF_001 Handle 0x000A, DMI type 131, 64 bytes OEM-specific Type Header and Data: 83 40 0A 00 31 00 00 00 00 00 00 00 00 00 00 00 F8 00 56 1E FF FF FF FF 01 20 00 00 01 00 08 00 E0 04 00 00 00 00 00 00 C8 00 FF FF 00 00 00 00 00 00 00 00 A2 00 00 00 76 50 72 6F 00 00 00 00 Handle 0x0000, DMI type 0, 24 bytes BIOS Information Vendor: Dell Inc. Version: A09 Release Date: 05/15/2013 Address: 0xE0000 Runtime Size: 128 kB ROM Size: 6656 kB Characteristics: PCI is supported PNP is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported Selectable boot is supported EDD is supported 5.25"/360 kB floppy services are supported (int 13h) 5.25"/1.2 MB floppy services are supported (int 13h) 3.5"/720 kB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported LS-120 boot is supported Smart battery is supported BIOS boot specification is supported Function key-initiated network boot is supported Targeted content distribution is supported BIOS Revision: 0.1 Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: Dell Inc. Product Name: Dell System XPS L322X Version: Not Specified Wake-up Type: APM Timer SKU Number: Dell System XPS L322X Family: ChiefRiver System Handle 0x0002, DMI type 2, 15 bytes Base Board Information Manufacturer: Dell Inc. Product Name: 0PJHXN Version: A00 Serial Number: .CGLH1Y1.CN4864337C0032. Asset Tag: Features: Board is a hosting board Board is replaceable Location In Chassis: Part Component Chassis Handle: 0x0000 Type: Motherboard Contained Object Handles: 0 Handle 0x0003, DMI type 3, 22 bytes Chassis Information Manufacturer: Dell Inc. Type: Portable Lock: Not Present Version: 0.1 Serial Number: CGLH1Y1 Asset Tag: Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: None OEM Information: 0x00000000 Height: Unspecified Number Of Power Cords: 1 Contained Elements: 0 SKU Number: System SKUNumber Handle 0x000B, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: None Internal Connector Type: None External Reference Designator: Keyboard External Connector Type: PS/2 Port Type: Keyboard Port Handle 0x000C, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: None Internal Connector Type: None External Reference Designator: Mouse External Connector Type: PS/2 Port Type: Mouse Port Handle 0x000D, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: None Internal Connector Type: Other External Reference Designator: COM 1 External Connector Type: DB-9 male Port Type: Serial Port 16550A Compatible Handle 0x000E, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: None Internal Connector Type: None External Reference Designator: USB3.0 - 1#/USB2.0 - 1# External Connector Type: Access Bus (USB) Port Type: USB Handle 0x000F, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: None Internal Connector Type: None External Reference Designator: USB3.0 - 2#/USB2.0 - 2# External Connector Type: Access Bus (USB) Port Type: USB Handle 0x0010, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: None Internal Connector Type: None External Reference Designator: USB3.0 - 3#/USB2.0 - 3# External Connector Type: Access Bus (USB) Port Type: USB Handle 0x0011, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: None Internal Connector Type: None External Reference Designator: USB3.0 - 4#/USB2.0 - 4# External Connector Type: Access Bus (USB) Port Type: USB Handle 0x0012, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: None Internal Connector Type: None External Reference Designator: USB2.0 - 5# External Connector Type: Access Bus (USB) Port Type: USB Handle 0x0013, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: None Internal Connector Type: None External Reference Designator: None External Connector Type: Access Bus (USB) Port Type: USB Handle 0x0014, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: None Internal Connector Type: None External Reference Designator: None External Connector Type: Access Bus (USB) Port Type: USB Handle 0x0015, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: None Internal Connector Type: None External Reference Designator: None External Connector Type: Access Bus (USB) Port Type: USB Handle 0x0016, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: None Internal Connector Type: None External Reference Designator: USB2.0 - 9# External Connector Type: Access Bus (USB) Port Type: USB Handle 0x0017, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: None Internal Connector Type: None External Reference Designator: None External Connector Type: Access Bus (USB) Port Type: USB Handle 0x0018, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: None Internal Connector Type: None External Reference Designator: USB2.0 - 11# External Connector Type: Access Bus (USB) Port Type: USB Handle 0x0019, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: None Internal Connector Type: None External Reference Designator: USB2.0 - 12# External Connector Type: Access Bus (USB) Port Type: USB Handle 0x001A, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: None Internal Connector Type: None External Reference Designator: USB2.0 - 13# External Connector Type: Access Bus (USB) Port Type: USB Handle 0x001B, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: None Internal Connector Type: None External Reference Designator: USB2.0 - 14# External Connector Type: Access Bus (USB) Port Type: USB Handle 0x001C, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: None Internal Connector Type: None External Reference Designator: Ethernet External Connector Type: RJ-45 Port Type: Network Port Handle 0x001D, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: SATA Port 1 J8J1 Internal Connector Type: SAS/SATA Plug Receptacle External Reference Designator: None External Connector Type: None Port Type: SATA Handle 0x001E, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: SATA Port 2 J7G1 Internal Connector Type: SAS/SATA Plug Receptacle External Reference Designator: None External Connector Type: None Port Type: SATA Handle 0x001F, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: SATA Port 3(ODD) J9E7 Internal Connector Type: SAS/SATA Plug Receptacle External Reference Designator: None External Connector Type: None Port Type: SATA Handle 0x0020, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: None Internal Connector Type: None External Reference Designator: None External Connector Type: SAS/SATA Plug Receptacle Port Type: SATA Handle 0x0021, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: None Internal Connector Type: None External Reference Designator: None External Connector Type: SAS/SATA Plug Receptacle Port Type: SATA Handle 0x0022, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: None Internal Connector Type: None External Reference Designator: SATA Port 6(Docking) External Connector Type: SAS/SATA Plug Receptacle Port Type: SATA Handle 0x0023, DMI type 9, 17 bytes System Slot Information Designation: PEG Gen1/Gen2/Gen3 X16 Type: x16 PCI Express Current Usage: Available Length: Long ID: 0 Characteristics: 3.3 V is provided Opening is shared PME signal is supported Bus Address: 0000:00:00.0 Handle 0x0024, DMI type 9, 17 bytes System Slot Information Designation: PCI-Express 1 X1 Type: x1 PCI Express Current Usage: In Use Length: Short ID: 1 Characteristics: 3.3 V is provided Opening is shared PME signal is supported Bus Address: 0000:00:00.0 Handle 0x0025, DMI type 9, 17 bytes System Slot Information Designation: PCI-Express 2 X1 Type: x1 PCI Express Current Usage: Available Length: Short ID: 2 Characteristics: 3.3 V is provided Opening is shared PME signal is supported Bus Address: 0000:00:00.0 Handle 0x0026, DMI type 9, 17 bytes System Slot Information Designation: PCI-Express 3 X1 Type: x1 PCI Express Current Usage: Available Length: Short ID: 3 Characteristics: 3.3 V is provided Opening is shared PME signal is supported Bus Address: 0000:00:00.0 Handle 0x0027, DMI type 9, 17 bytes System Slot Information Designation: PCI-Express 4 X1 Type: x1 PCI Express Current Usage: Available Length: Short ID: 4 Characteristics: 3.3 V is provided Opening is shared PME signal is supported Bus Address: 0000:00:00.0 Handle 0x0028, DMI type 9, 17 bytes System Slot Information Designation: PCI-Express 5 X4 Type: x4 PCI Express Current Usage: Available Length: Short ID: 5 Characteristics: 3.3 V is provided Opening is shared PME signal is supported Bus Address: 0000:00:00.0 Handle 0x0029, DMI type 10, 6 bytes On Board Device Information Type: Video Status: Enabled Description: Intel(R) Extreme Graphics 3 Controller Handle 0x002A, DMI type 10, 6 bytes On Board Device Information Type: Sound Status: Enabled Description: Intel(R) Azalia Audio Device Handle 0x002C, DMI type 12, 5 bytes System Configuration Options Handle 0x002D, DMI type 13, 22 bytes BIOS Language Information Language Description Format: Abbreviated Installable Languages: 7 enUS frFR jaJP koKR zhCA zhCA ruRU Currently Installed Language: enUS Handle 0x002E, DMI type 22, 26 bytes Portable Battery Location: Rear Manufacturer: Dynapack Manufacture Date: 2008 Serial Number: 1.0 Name: DELL Design Capacity: 46620 mWh Design Voltage: 7400 mV SBDS Version: V1.0 Maximum Error: Unknown SBDS Chemistry: LION OEM-specific Information: 0x00000000 Handle 0x002F, DMI type 32, 11 bytes System Boot Information Status: No errors detected Handle 0x0030, DMI type 18, 23 bytes 32-bit Memory Error Information Type: OK Granularity: Unknown Operation: Unknown Vendor Syndrome: Unknown Memory Array Address: Unknown Device Address: Unknown Resolution: Unknown Handle 0x0031, DMI type 21, 7 bytes Built-in Pointing Device Type: Touch Pad Interface: PS/2 Buttons: 2 Handle 0x0032, DMI type 23, 13 bytes System Reset Status: Disabled Watchdog Timer: Present Boot Option: Do Not Reboot Boot Option On Limit: Do Not Reboot Reset Count: Unknown Reset Limit: Unknown Timer Interval: Unknown Timeout: Unknown Handle 0x0033, DMI type 24, 5 bytes Hardware Security Power-On Password Status: Unknown Keyboard Password Status: Unknown Administrator Password Status: Unknown Front Panel Reset Status: Unknown Handle 0x0034, DMI type 27, 14 bytes Cooling Device Type: Fan Status: OK OEM-specific Information: 0x00000000 Nominal Speed: 0 rpm Handle 0x0035, DMI type 16, 23 bytes Physical Memory Array Location: System Board Or Motherboard Use: System Memory Error Correction Type: None Maximum Capacity: 8 GB Error Information Handle: Not Provided Number Of Devices: 2 Handle 0x0036, DMI type 17, 34 bytes Memory Device Array Handle: 0x0035 Error Information Handle: Not Provided Total Width: 64 bits Data Width: 64 bits Size: 4096 MB Form Factor: DIMM Set: None Locator: ChannelA-DIMM0 Bank Locator: BANK 0 Type: DDR3 Type Detail: Synchronous Speed: 1600 MHz Manufacturer: Hynix/Hyundai Serial Number: 00000000 Asset Tag: 9876543210 Part Number: HT5SMRAP Rank: Unknown Configured Clock Speed: 1600 MHz Handle 0x0037, DMI type 17, 34 bytes Memory Device Array Handle: 0x0035 Error Information Handle: Not Provided Total Width: 64 bits Data Width: 64 bits Size: 4096 MB Form Factor: DIMM Set: None Locator: ChannelB-DIMM0 Bank Locator: BANK 2 Type: DDR3 Type Detail: Synchronous Speed: 1600 MHz Manufacturer: Hynix/Hyundai Serial Number: 00000000 Asset Tag: 9876543210 Part Number: HT5SMRAP Rank: Unknown Configured Clock Speed: 1600 MHz Handle 0x0038, DMI type 20, 35 bytes Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000FFFFFFFF Range Size: 4 GB Physical Device Handle: 0x0036 Memory Array Mapped Address Handle: 0x003A Partition Row Position: 1 Handle 0x0039, DMI type 20, 35 bytes Memory Device Mapped Address Starting Address: 0x00100000000 Ending Address: 0x001FFFFFFFF Range Size: 4 GB Physical Device Handle: 0x0036 Memory Array Mapped Address Handle: 0x003A Partition Row Position: 1 Handle 0x003A, DMI type 19, 31 bytes Memory Array Mapped Address Starting Address: 0x00000000000 Ending Address: 0x001FFFFFFFF Range Size: 8 GB Physical Array Handle: 0x0035 Partition Width: 2 Handle 0x003B, DMI type 176, 5 bytes OEM-specific Type Header and Data: B0 05 3B 00 00 Handle 0x003C, DMI type 177, 12 bytes OEM-specific Type Header and Data: B1 0C 3C 00 1A 0E 00 00 00 00 00 00 Handle 0x003D, DMI type 208, 16 bytes OEM-specific Type Header and Data: D0 10 3D 00 01 05 FE 00 8B 05 01 02 00 00 00 00 Strings: 20100730 20100430 Handle 0x003E, DMI type 212, 17 bytes OEM-specific Type Header and Data: D4 11 3E 00 70 00 71 00 00 10 2D 2E FF FF 00 00 00 Handle 0x003F, DMI type 216, 9 bytes OEM-specific Type Header and Data: D8 09 3F 00 01 02 01 F0 03 Strings: Intel 213 Handle 0x0040, DMI type 217, 8 bytes OEM-specific Type Header and Data: D9 08 40 00 01 02 01 03 Strings: US-101 Proprietary Handle 0x0041, DMI type 220, 22 bytes OEM-specific Type Header and Data: DC 16 41 00 01 F0 00 00 02 F0 00 00 03 F0 04 F0 00 00 00 00 00 00 Handle 0x0042, DMI type 221, 19 bytes OEM-specific Type Header and Data: DD 13 42 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Handle 0x0043, DMI type 222, 16 bytes OEM-specific Type Header and Data: DE 10 43 00 01 02 FF FF 00 00 00 00 00 00 00 00 Handle 0xDA00, DMI type 218, 251 bytes OEM-specific Type Header and Data: DA FB 00 DA B2 00 D2 1B 0F B6 40 7D 00 00 00 00 00 80 01 16 00 01 00 7F 01 16 00 00 00 52 01 17 00 01 00 53 01 17 00 00 00 7C 01 18 00 01 00 7B 01 18 00 00 00 2E 00 25 00 00 00 2D 00 25 00 01 00 6E 00 25 00 01 00 8A 01 48 00 01 00 89 01 48 00 00 00 9B 00 23 00 01 00 9C 00 23 00 00 00 2D 01 50 00 01 00 2E 01 50 00 00 00 14 01 46 00 00 00 15 01 46 00 01 00 16 01 46 00 02 00 8E 01 68 00 01 00 8D 01 68 00 00 00 94 01 47 00 01 00 93 01 47 00 00 00 EA 00 67 00 01 00 EB 00 67 00 00 00 00 FE 00 00 00 00 01 FE 00 00 01 00 A0 FE 00 00 00 00 A1 FE 00 00 01 00 E1 01 01 00 00 00 E2 01 01 00 01 00 E3 01 01 00 02 00 DC 01 02 00 00 00 DD 01 02 00 01 00 A5 02 70 00 01 00 A6 02 70 00 00 00 0C 80 89 00 00 00 4A 02 89 00 01 00 04 A0 89 00 02 00 FF FF 00 00 00 00 Handle 0xDA01, DMI type 218, 245 bytes OEM-specific Type Header and Data: DA F5 01 DA B2 00 D2 1B 0F B6 40 ED 00 73 00 00 00 EE 00 73 00 00 00 EF 00 73 00 00 00 F0 00 73 00 01 00 0E 01 74 00 01 00 0F 01 74 00 00 00 35 01 75 00 00 00 36 01 75 00 00 00 37 01 75 00 00 00 38 01 75 00 01 00 39 01 75 00 02 00 FE 01 75 00 00 00 3C 03 75 00 02 00 44 01 76 00 00 00 45 01 76 00 01 00 46 01 77 00 00 00 47 01 77 00 01 00 3E 03 78 00 00 00 3D 03 78 00 01 00 4A 01 79 00 00 00 4B 01 79 00 01 00 3B 03 80 00 00 00 3A 03 80 00 01 00 36 02 81 00 00 00 35 02 81 00 01 00 75 01 75 01 00 00 3F 03 75 01 01 00 76 01 75 01 02 00 09 01 23 00 00 00 33 01 82 00 00 00 34 01 82 00 01 00 3A 01 83 00 00 00 3B 01 83 00 01 00 3C 01 83 00 02 00 3D 01 84 00 00 00 3E 01 84 00 01 00 56 01 85 00 00 00 57 01 85 00 01 00 FF FF 00 00 00 00 Handle 0x0044, DMI type 218, 53 bytes OEM-specific Type Header and Data: DA 35 44 00 B2 00 D2 1B 0F B6 40 5B 03 86 00 01 00 5C 03 86 00 00 00 5D 03 87 00 01 00 5E 03 87 00 00 00 5F 03 88 00 01 00 60 03 88 00 00 00 FF FF 00 00 00 00 Handle 0x002B, DMI type 11, 5 bytes OEM Strings String 1: Dell System String 2: 1[058B] String 3: 13[PP36S] String 4: 14[3] String 5: 15[9] Handle 0xFEFF, DMI type 127, 4 bytes End Of Table ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight) 2013-07-24 6:49 ` James Hogan @ 2013-07-24 7:14 ` Mike Galbraith 2013-07-24 7:19 ` Igor Gnatenko 1 sibling, 0 replies; 71+ messages in thread From: Mike Galbraith @ 2013-07-24 7:14 UTC (permalink / raw) To: James Hogan Cc: Rafael J. Wysocki, Kamal Mostafa, Steven Newbury, Martin Steigerwald, Jörg Otte, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, ACPI Devel Maling List On Wed, 2013-07-24 at 07:49 +0100, James Hogan wrote: > On 24 July 2013 01:05, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > I'd like to collect some information on the systems having problems with those > > two commits (to see if they are similar somehow). > > > > It seems that one common symptom is that brightness cannot be controlled > > through function keys. Is that correct for all of you? If so, did you try > > any other way to control brightness, like a GUI-based? > > For me both the Fn keys and the gui slider (kde) now control > /sys/class/backlight/intel_backlight/brightness (which has no effect). > Previously they both controlled the acpi one (that on -rc2 doesn't > exist). Hm, poking Fn keys make kde slider widget appear on my Toshiba Satellite but do nada, never did, and I never looked into it, assumed there was no canned functionality for my lappy, so use a setpci script instead. Lappy has acpi_video0, which gui is twiddling, and does nothing, as does toshiba, while intel_backlight works. Suppose I should put latest/greatest kernel on the thing, maybe my Fn keys will magically start turning the _right_ knob. -Mike ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight) 2013-07-24 6:49 ` James Hogan @ 2013-07-24 7:19 ` Igor Gnatenko 2013-07-24 7:19 ` Igor Gnatenko 1 sibling, 0 replies; 71+ messages in thread From: Igor Gnatenko @ 2013-07-24 7:19 UTC (permalink / raw) To: James Hogan Cc: Rafael J. Wysocki, Kamal Mostafa, Steven Newbury, Martin Steigerwald, Jörg Otte, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, ACPI Devel Maling List, Aaron Lu On Wed, 2013-07-24 at 07:49 +0100, James Hogan wrote: > On 24 July 2013 01:05, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > I'd like to collect some information on the systems having problems with those > > two commits (to see if they are similar somehow). > > > > It seems that one common symptom is that brightness cannot be controlled > > through function keys. Is that correct for all of you? If so, did you try > > any other way to control brightness, like a GUI-based? > > For me both the Fn keys and the gui slider (kde) now control > /sys/class/backlight/intel_backlight/brightness (which has no effect). > Previously they both controlled the acpi one (that on -rc2 doesn't > exist). I think this problem in i915 drivers. Rafael, Mathew, Aaron, fix me please > > > > > Also, can you all please send me (a) the output of dmidecode and (b) the > > contents of /proc/cpuinfo from your systems? > > attached -- Igor Gnatenko Fedora release 19 (Schrödinger’s Cat) Linux 3.9.9-302.fc19.x86_64 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight) @ 2013-07-24 7:19 ` Igor Gnatenko 0 siblings, 0 replies; 71+ messages in thread From: Igor Gnatenko @ 2013-07-24 7:19 UTC (permalink / raw) To: James Hogan Cc: Rafael J. Wysocki, Kamal Mostafa, Steven Newbury, Martin Steigerwald, Jörg Otte, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, ACPI Devel Maling List, Aaron Lu On Wed, 2013-07-24 at 07:49 +0100, James Hogan wrote: > On 24 July 2013 01:05, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > I'd like to collect some information on the systems having problems with those > > two commits (to see if they are similar somehow). > > > > It seems that one common symptom is that brightness cannot be controlled > > through function keys. Is that correct for all of you? If so, did you try > > any other way to control brightness, like a GUI-based? > > For me both the Fn keys and the gui slider (kde) now control > /sys/class/backlight/intel_backlight/brightness (which has no effect). > Previously they both controlled the acpi one (that on -rc2 doesn't > exist). I think this problem in i915 drivers. Rafael, Mathew, Aaron, fix me please > > > > > Also, can you all please send me (a) the output of dmidecode and (b) the > > contents of /proc/cpuinfo from your systems? > > attached -- Igor Gnatenko Fedora release 19 (Schrödinger’s Cat) Linux 3.9.9-302.fc19.x86_64 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight) 2013-07-24 7:19 ` Igor Gnatenko (?) @ 2013-07-24 12:06 ` Rafael J. Wysocki -1 siblings, 0 replies; 71+ messages in thread From: Rafael J. Wysocki @ 2013-07-24 12:06 UTC (permalink / raw) To: Igor Gnatenko Cc: James Hogan, Kamal Mostafa, Steven Newbury, Martin Steigerwald, Jörg Otte, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, ACPI Devel Maling List, Aaron Lu On Wednesday, July 24, 2013 11:19:10 AM Igor Gnatenko wrote: > On Wed, 2013-07-24 at 07:49 +0100, James Hogan wrote: > > On 24 July 2013 01:05, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > > I'd like to collect some information on the systems having problems with those > > > two commits (to see if they are similar somehow). > > > > > > It seems that one common symptom is that brightness cannot be controlled > > > through function keys. Is that correct for all of you? If so, did you try > > > any other way to control brightness, like a GUI-based? > > > > For me both the Fn keys and the gui slider (kde) now control > > /sys/class/backlight/intel_backlight/brightness (which has no effect). > > Previously they both controlled the acpi one (that on -rc2 doesn't > > exist). > I think this problem in i915 drivers. > Rafael, Mathew, Aaron, fix me please Yes, it is my impression too. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight) 2013-07-24 0:05 ` Rafael J. Wysocki 2013-07-24 4:54 ` Steven Newbury 2013-07-24 6:49 ` James Hogan @ 2013-07-24 11:45 ` Jörg Otte 2 siblings, 0 replies; 71+ messages in thread From: Jörg Otte @ 2013-07-24 11:45 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Kamal Mostafa, James Hogan, Steven Newbury, Martin Steigerwald, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, ACPI Devel Maling List 2013/7/24 Rafael J. Wysocki <rjw@sisk.pl>: > On Tuesday, July 23, 2013 11:46:29 AM Kamal Mostafa wrote: >> On Mon, 2013-07-22 at 21:54 +0200, Rafael J. Wysocki wrote: >> > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote: >> > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: >> > > > >> > > > Linus, do you want me to send a pull request reverting 8c5bd7a and efaa14c? >> > > >> > > Yes, but [...] I'd suggest doing the revert just in time for >> > > rc3, but waiting until then to gather info about people who see >> > > breakage. >> > > >> > > Sound like a plan? >> > >> > Yes, it does. >> > >> > Rafael >> >> >> Hi Rafael- >> >> For your reference... >> >> As James Hogan reported, those ACPI changes break backlight control on >> the "Dell XPS13" Ivy Bridge models (the Sandy Bridge XPS13 model is not >> affected). >> >> I confirm that reverting 8c5bd7a and efaa14c fixes it again. > > Thanks! > > I'd like to collect some information on the systems having problems with those > two commits (to see if they are similar somehow). > > It seems that one common symptom is that brightness cannot be controlled > through function keys. Is that correct for all of you? Yes > If so, did you try > any other way to control brightness, like a GUI-based? Yes, it has no visible effect. > Also, can you all please send me (a) the output of dmidecode and (b) the > contents of /proc/cpuinfo from your systems? # dmidecode 2.11 # SMBIOS entry point at 0xdae8b000 SMBIOS 2.7 present. 36 structures occupying 1727 bytes. Table at 0x000E0B70. Handle 0x0000, DMI type 4, 42 bytes Processor Information Socket Designation: CPU Socket - U3E1 Type: Central Processor Family: Core i7 Manufacturer: Intel(R) Corporation ID: A9 06 03 00 FF FB EB BF Signature: Type 0, Family 6, Model 58, Stepping 9 Flags: FPU (Floating-point unit on-chip) VME (Virtual mode extension) DE (Debugging extension) PSE (Page size extension) TSC (Time stamp counter) MSR (Model specific registers) PAE (Physical address extension) MCE (Machine check exception) CX8 (CMPXCHG8 instruction supported) APIC (On-chip APIC hardware supported) SEP (Fast system call) MTRR (Memory type range registers) PGE (Page global enable) MCA (Machine check architecture) CMOV (Conditional move instruction supported) PAT (Page attribute table) PSE-36 (36-bit page size extension) CLFSH (CLFLUSH instruction supported) DS (Debug store) ACPI (ACPI supported) MMX (MMX technology supported) FXSR (FXSAVE and FXSTOR instructions supported) SSE (Streaming SIMD extensions) SSE2 (Streaming SIMD extensions 2) SS (Self-snoop) HTT (Multi-threading) TM (Thermal monitor supported) PBE (Pending break enabled) Version: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz Voltage: 0.9 V External Clock: 100 MHz Max Speed: 2500 MHz Current Speed: 2500 MHz Status: Populated, Enabled Upgrade: Socket rPGA988B L1 Cache Handle: 0x0002 L2 Cache Handle: 0x0003 L3 Cache Handle: 0x0004 Serial Number: To Be Filled By O.E.M. Asset Tag: To Be Filled By O.E.M. Part Number: To Be Filled By O.E.M. Core Count: 2 Core Enabled: 2 Thread Count: 4 Characteristics: 64-bit capable Handle 0x0001, DMI type 7, 19 bytes Cache Information Socket Designation: L1-Cache Configuration: Enabled, Not Socketed, Level 1 Operational Mode: Write Through Location: Internal Installed Size: 32 kB Maximum Size: 32 kB Supported SRAM Types: Unknown Installed SRAM Type: Unknown Speed: Unknown Error Correction Type: Parity System Type: Data Associativity: 8-way Set-associative Handle 0x0002, DMI type 7, 19 bytes Cache Information Socket Designation: L1-Cache Configuration: Enabled, Not Socketed, Level 1 Operational Mode: Write Through Location: Internal Installed Size: 32 kB Maximum Size: 32 kB Supported SRAM Types: Unknown Installed SRAM Type: Unknown Speed: Unknown Error Correction Type: Parity System Type: Instruction Associativity: 8-way Set-associative Handle 0x0003, DMI type 7, 19 bytes Cache Information Socket Designation: L2-Cache Configuration: Enabled, Not Socketed, Level 2 Operational Mode: Write Through Location: Internal Installed Size: 256 kB Maximum Size: 256 kB Supported SRAM Types: Unknown Installed SRAM Type: Unknown Speed: Unknown Error Correction Type: Multi-bit ECC System Type: Unified Associativity: 8-way Set-associative Handle 0x0004, DMI type 7, 19 bytes Cache Information Socket Designation: L3-Cache Configuration: Enabled, Not Socketed, Level 3 Operational Mode: Write Back Location: Internal Installed Size: 3072 kB Maximum Size: 3072 kB Supported SRAM Types: Unknown Installed SRAM Type: Unknown Speed: Unknown Error Correction Type: Multi-bit ECC System Type: Unified Associativity: 12-way Set-associative Handle 0x0005, DMI type 129, 8 bytes OEM-specific Type Header and Data: 81 08 05 00 01 01 02 01 Strings: Intel_ASF Intel_ASF_001 Handle 0x0006, DMI type 131, 64 bytes OEM-specific Type Header and Data: 83 40 06 00 31 00 00 00 00 00 00 00 00 00 00 00 F8 00 59 1E FF FF FF FF 01 20 00 00 00 00 08 00 93 05 03 00 00 00 00 00 C8 00 FF FF 00 00 00 00 00 00 00 00 60 00 00 00 76 50 72 6F 00 00 00 00 Handle 0x0007, DMI type 16, 23 bytes Physical Memory Array Location: System Board Or Motherboard Use: System Memory Error Correction Type: None Maximum Capacity: 32 GB Error Information Handle: Not Provided Number Of Devices: 4 Handle 0x0008, DMI type 17, 34 bytes Memory Device Array Handle: 0x0007 Error Information Handle: Not Provided Total Width: 64 bits Data Width: 64 bits Size: 4096 MB Form Factor: SODIMM Set: None Locator: ChannelA-DIMM0 Bank Locator: BANK 0 Type: DDR3 Type Detail: Synchronous Speed: 1600 MHz Manufacturer: Hynix/Hyundai Serial Number: 31480B56 Asset Tag: 9876543210 Part Number: HMT351S6CFR8A-PB Rank: Unknown Configured Clock Speed: 1600 MHz Handle 0x0009, DMI type 17, 34 bytes Memory Device Array Handle: 0x0007 Error Information Handle: Not Provided Total Width: Unknown Data Width: Unknown Size: No Module Installed Form Factor: DIMM Set: None Locator: ChannelA-DIMM1 Bank Locator: BANK 1 Type: Unknown Type Detail: None Speed: Unknown Manufacturer: Not Specified Serial Number: Not Specified Asset Tag: 9876543210 Part Number: Not Specified Rank: Unknown Configured Clock Speed: Unknown Handle 0x000A, DMI type 17, 34 bytes Memory Device Array Handle: 0x0007 Error Information Handle: Not Provided Total Width: 64 bits Data Width: 64 bits Size: 4096 MB Form Factor: SODIMM Set: None Locator: ChannelB-DIMM0 Bank Locator: BANK 2 Type: DDR3 Type Detail: Synchronous Speed: 1600 MHz Manufacturer: Kingston Serial Number: AE20A7A4 Asset Tag: 9876543210 Part Number: 9905428-085.A00G Rank: Unknown Configured Clock Speed: 1600 MHz Handle 0x000B, DMI type 17, 34 bytes Memory Device Array Handle: 0x0007 Error Information Handle: Not Provided Total Width: Unknown Data Width: Unknown Size: No Module Installed Form Factor: DIMM Set: None Locator: ChannelB-DIMM1 Bank Locator: BANK 3 Type: Unknown Type Detail: None Speed: Unknown Manufacturer: Not Specified Serial Number: Not Specified Asset Tag: 9876543210 Part Number: Not Specified Rank: Unknown Configured Clock Speed: Unknown Handle 0x000C, DMI type 20, 35 bytes Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x001FFFFFFFF Range Size: 8 GB Physical Device Handle: 0x0008 Memory Array Mapped Address Handle: 0x000E Partition Row Position: 1 Interleave Position: 1 Interleaved Data Depth: 2 Handle 0x000D, DMI type 20, 35 bytes Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x001FFFFFFFF Range Size: 8 GB Physical Device Handle: 0x0009 Memory Array Mapped Address Handle: 0x000E Partition Row Position: 1 Interleave Position: 2 Interleaved Data Depth: 2 Handle 0x000E, DMI type 19, 31 bytes Memory Array Mapped Address Starting Address: 0x00000000000 Ending Address: 0x001FFFFFFFF Range Size: 8 GB Physical Array Handle: 0x0007 Partition Width: 4 Handle 0x000F, DMI type 0, 24 bytes BIOS Information Vendor: FUJITSU // Phoenix Technologies Ltd. Version: Version 1.09 Release Date: 05/22/2012 Address: 0xE0000 Runtime Size: 128 kB ROM Size: 4096 kB Characteristics: PCI is supported PC Card (PCMCIA) is supported PNP is supported BIOS is upgradeable BIOS shadowing is allowed Boot from CD is supported Selectable boot is supported EDD is supported 3.5"/720 kB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported BIOS boot specification is supported Function key-initiated network boot is supported Targeted content distribution is supported UEFI is supported BIOS Revision: 1.9 Handle 0x0010, DMI type 1, 27 bytes System Information Manufacturer: FUJITSU Product Name: LIFEBOOK AH532 Version: Serial Number: YLKV045679 UUID: ABAF1C3F-6808-E211-9C17-5C9AD8692B39 Wake-up Type: Power Switch SKU Number: Family: Handle 0x0011, DMI type 2, 15 bytes Base Board Information Manufacturer: FUJITSU Product Name: FJNBB1C Version: Serial Number: 578102-01R2602242 Asset Tag: Features: Board is a hosting board Location In Chassis: Chassis Handle: 0x0000 Type: Motherboard Contained Object Handles: 0 Handle 0x0012, DMI type 3, 22 bytes Chassis Information Manufacturer: FUJITSU Type: Notebook Lock: Not Present Version: Serial Number: YLKV045679 Asset Tag: Boot-up State: Unknown Power Supply State: Unknown Thermal State: Unknown Security Status: Unknown OEM Information: 0x00000000 Height: Unspecified Number Of Power Cords: Unspecified Contained Elements: 0 SKU Number: Not Specified Handle 0x0013, DMI type 11, 5 bytes OEM Strings String 1: fAjTCRFj91ObS String 2: 3gwdwbZfdahV4 String 3: REFrSQarvBTce Handle 0x0014, DMI type 12, 5 bytes System Configuration Options Option 1: SMI:00B2C801 Option 2: TIM:201307241127 Option 3: HDD: 826KC34UT Option 4: MEM:HMT351S6CFR8A-PB 31480B56 Handle 0x0015, DMI type 13, 22 bytes BIOS Language Information Language Description Format: Abbreviated Installable Languages: 7 en-US fr-FR ja-JP ko-KR zh-CHT zh-CHS ru-RU Currently Installed Language: en-US Handle 0x0016, DMI type 22, 26 bytes Portable Battery Location: Internal Battery Manufacturer: FUJITSU Manufacture Date: Serial Number: CP5677170101120602120416006746 Name: CP567717-01 Chemistry: Lithium Ion Design Capacity: 47520 mWh Design Voltage: 10800 mV SBDS Version: V1.0 Maximum Error: Unknown OEM-specific Information: 0x00000000 Handle 0x0017, DMI type 32, 11 bytes System Boot Information Status: No errors detected Handle 0x0018, DMI type 143, 16 bytes OEM-specific Type Header and Data: 8F 10 18 00 00 5F 46 4A 5F 4F 45 4D 5F 12 00 00 Handle 0x0019, DMI type 143, 8 bytes OEM-specific Type Header and Data: 8F 08 19 00 01 03 00 00 Handle 0x001A, DMI type 143, 11 bytes OEM-specific Type Header and Data: 8F 0B 1A 00 02 00 01 00 03 56 05 Handle 0x001B, DMI type 143, 11 bytes OEM-specific Type Header and Data: 8F 0B 1B 00 02 06 01 15 37 AF 0D Handle 0x001C, DMI type 143, 11 bytes OEM-specific Type Header and Data: 8F 0B 1C 00 02 01 01 01 00 00 00 Handle 0x001D, DMI type 143, 11 bytes OEM-specific Type Header and Data: 8F 0B 1D 00 02 02 01 01 00 00 00 Handle 0x001E, DMI type 143, 11 bytes OEM-specific Type Header and Data: 8F 0B 1E 00 02 05 01 00 00 00 00 Handle 0x001F, DMI type 136, 6 bytes OEM-specific Type Header and Data: 88 06 1F 00 5A 5A Handle 0x0020, DMI type 21, 7 bytes Built-in Pointing Device Type: Other Interface: PS/2 Buttons: 2 Handle 0x0021, DMI type 24, 5 bytes Hardware Security Power-On Password Status: Disabled Keyboard Password Status: Not Implemented Administrator Password Status: Enabled Front Panel Reset Status: Not Implemented Handle 0x0022, DMI type 15, 105 bytes System Event Log Area Length: 114 bytes Header Start Offset: 0x0000 Header Length: 16 bytes Data Start Offset: 0x0010 Access Method: General-purpose non-volatile data functions Access Address: 0x00F0 Status: Valid, Not Full Change Token: 0x00000006 Header Format: Type 1 Supported Log Type Descriptors: 41 Descriptor 1: Single-bit ECC memory error Data Format 1: Multiple-event handle Descriptor 2: Multi-bit ECC memory error Data Format 2: Multiple-event handle Descriptor 3: Parity memory error Data Format 3: None Descriptor 4: Bus timeout Data Format 4: None Descriptor 5: I/O channel block Data Format 5: None Descriptor 6: Software NMI Data Format 6: None Descriptor 7: POST memory resize Data Format 7: None Descriptor 8: POST error Data Format 8: POST results bitmap Descriptor 9: PCI parity error Data Format 9: None Descriptor 10: PCI system error Data Format 10: None Descriptor 11: CPU failure Data Format 11: None Descriptor 12: EISA failsafe timer timeout Data Format 12: None Descriptor 13: Correctable memory log disabled Data Format 13: None Descriptor 14: Logging disabled Data Format 14: None Descriptor 15: System limit exceeded Data Format 15: None Descriptor 16: Asynchronous hardware timer expired Data Format 16: None Descriptor 17: System configuration information Data Format 17: None Descriptor 18: Hard disk information Data Format 18: None Descriptor 19: System reconfigured Data Format 19: None Descriptor 20: Uncorrectable CPU-complex error Data Format 20: None Descriptor 21: Log area reset/cleared Data Format 21: None Descriptor 22: System boot Data Format 22: None Descriptor 23: OEM-specific Data Format 23: None Descriptor 24: OEM-specific Data Format 24: None Descriptor 25: OEM-specific Data Format 25: None Descriptor 26: OEM-specific Data Format 26: None Descriptor 27: OEM-specific Data Format 27: None Descriptor 28: OEM-specific Data Format 28: None Descriptor 29: OEM-specific Data Format 29: None Descriptor 30: OEM-specific Data Format 30: None Descriptor 31: OEM-specific Data Format 31: None Descriptor 32: OEM-specific Data Format 32: None Descriptor 33: OEM-specific Data Format 33: None Descriptor 34: OEM-specific Data Format 34: None Descriptor 35: OEM-specific Data Format 35: None Descriptor 36: OEM-specific Data Format 36: None Descriptor 37: OEM-specific Data Format 37: None Descriptor 38: OEM-specific Data Format 38: None Descriptor 39: OEM-specific Data Format 39: None Descriptor 40: OEM-specific Data Format 40: None Descriptor 41: OEM-specific Data Format 41: None Handle 0xFEFF, DMI type 127, 4 bytes End Of Table ~$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz stepping : 9 microcode : 0x12 cpu MHz : 1875.000 cache size : 3072 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 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 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 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms bogomips : 4989.01 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz stepping : 9 microcode : 0x12 cpu MHz : 1625.000 cache size : 3072 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid : 1 initial apicid : 1 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 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 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms bogomips : 4989.01 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz stepping : 9 microcode : 0x12 cpu MHz : 1700.000 cache size : 3072 KB physical id : 0 siblings : 4 core id : 1 cpu cores : 2 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 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 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms bogomips : 4989.01 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz stepping : 9 microcode : 0x12 cpu MHz : 1675.000 cache size : 3072 KB physical id : 0 siblings : 4 core id : 1 cpu cores : 2 apicid : 3 initial apicid : 3 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 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 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms bogomips : 4989.01 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight, revert) 2013-07-22 19:54 ` Rafael J. Wysocki @ 2013-07-25 13:00 ` Rafael J. Wysocki 2013-07-25 13:00 ` Rafael J. Wysocki 1 sibling, 0 replies; 71+ messages in thread From: Rafael J. Wysocki @ 2013-07-25 13:00 UTC (permalink / raw) To: James Hogan, Kamal Mostafa, Aaron Lu, Kalle Valo Cc: Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, Steven Newbury, ACPI Devel Maling List, Jörg Otte, Martin Steigerwald, Daniel Vetter, intel-gfx, Jani Nikula On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote: > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote: > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > > > > > Linus, do you want me to send a pull request reverting 8c5bd7a and efaa14c? > > > > Yes, but let's wait a while. Not because I think we'll fix the problem > > (hey, miracles might happen), but because I think it would be useful > > to couple the reverts with information about the particular machines > > that broke (and the people who reported it). So that when we > > inevitably try again, we can perhaps get some testing effort with > > those machines/people. > > > > It doesn't seem to be a show-stopped for a large number of people, so > > there's no huge hurry. I'd suggest doing the revert just in time for > > rc3, but waiting until then to gather info about people who see > > breakage. > > > > Sound like a plan? > > Yes, it does. OK, time to revert I guess. James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended patch fixes the backlight for you. Aaron, please double check if acpi_video_backlight_quirks() will still work as needed. Thanks, Rafael --- From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Subject: Revert "ACPI / video / i915: No ACPI backlight if firmware expects Windows 8" We attempted to address a regression introduced by commit a57f7f9 (ACPICA: Add Windows8/Server2012 string for _OSI method.) after which ACPI video backlight support doesn't work on a number of systems, because the relevant AML methods in the ACPI tables in their BIOSes become useless after the BIOS has been told that the OS is compatible with Windows 8. That problem is tracked by the bug entry at: https://bugzilla.kernel.org/show_bug.cgi?id=51231 Commit 8c5bd7a (ACPI / video / i915: No ACPI backlight if firmware expects Windows 8) introduced for this purpose essentially prevented the ACPI backlight support from being used if the BIOS had been told that the OS was compatible with Windows 8 and the i915 driver was loaded, in which case the backlight would always be handled by i915. Unfortunately, however, that turned out to cause problems with backlight to appear on multiple systems with symptoms indicating that i915 was unable to control the backlight on those systems as expected. For this reason, revert commit 8c5bd7a, but leave the function acpi_video_backlight_quirks() introduced by it, because another commit on top of it uses that function. References: https://lkml.org/lkml/2013/7/21/119 References: https://lkml.org/lkml/2013/7/22/261 References: https://lkml.org/lkml/2013/7/23/429 References: https://lkml.org/lkml/2013/7/23/459 References: https://lkml.org/lkml/2013/7/23/81 References: https://lkml.org/lkml/2013/7/24/27 Reported-by: James Hogan <james@albanarts.com> Reported-by: Steven Newbury <steve@snewbury.org.uk> Reported-by: Kamal Mostafa <kamal@canonical.com> Reported-by: Martin Steigerwald <Martin@lichtvoll.de> Reported-by: Jörg Otte <jrg.otte@gmail.com> Reported-by: Kalle Valo <kvalo@adurom.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> --- drivers/acpi/internal.h | 2 - drivers/acpi/video.c | 67 ++++------------------------------------ drivers/acpi/video_detect.c | 15 -------- drivers/gpu/drm/i915/i915_dma.c | 2 - include/acpi/video.h | 11 ------ include/linux/acpi.h | 1 6 files changed, 11 insertions(+), 87 deletions(-) Index: linux-pm/drivers/acpi/video.c =================================================================== --- linux-pm.orig/drivers/acpi/video.c +++ linux-pm/drivers/acpi/video.c @@ -897,7 +897,7 @@ static void acpi_video_device_find_cap(s if (acpi_video_init_brightness(device)) return; - if (acpi_video_verify_backlight_support()) { + if (acpi_video_backlight_support()) { struct backlight_properties props; struct pci_dev *pdev; acpi_handle acpi_parent; @@ -1344,8 +1344,8 @@ acpi_video_switch_brightness(struct acpi unsigned long long level_current, level_next; int result = -EINVAL; - /* no warning message if acpi_backlight=vendor or a quirk is used */ - if (!acpi_video_verify_backlight_support()) + /* no warning message if acpi_backlight=vendor is used */ + if (!acpi_video_backlight_support()) return 0; if (!device->brightness) @@ -1843,46 +1843,6 @@ static int acpi_video_bus_remove(struct return 0; } -static acpi_status video_unregister_backlight(acpi_handle handle, u32 lvl, - void *context, void **rv) -{ - struct acpi_device *acpi_dev; - struct acpi_video_bus *video; - struct acpi_video_device *dev, *next; - - if (acpi_bus_get_device(handle, &acpi_dev)) - return AE_OK; - - if (acpi_match_device_ids(acpi_dev, video_device_ids)) - return AE_OK; - - video = acpi_driver_data(acpi_dev); - if (!video) - return AE_OK; - - acpi_video_bus_stop_devices(video); - mutex_lock(&video->device_list_lock); - list_for_each_entry_safe(dev, next, &video->video_device_list, entry) { - if (dev->backlight) { - backlight_device_unregister(dev->backlight); - dev->backlight = NULL; - kfree(dev->brightness->levels); - kfree(dev->brightness); - } - if (dev->cooling_dev) { - sysfs_remove_link(&dev->dev->dev.kobj, - "thermal_cooling"); - sysfs_remove_link(&dev->cooling_dev->device.kobj, - "device"); - thermal_cooling_device_unregister(dev->cooling_dev); - dev->cooling_dev = NULL; - } - } - mutex_unlock(&video->device_list_lock); - acpi_video_bus_start_devices(video); - return AE_OK; -} - static int __init is_i740(struct pci_dev *dev) { if (dev->device == 0x00D1) @@ -1914,25 +1874,14 @@ static int __init intel_opregion_present return opregion; } -int __acpi_video_register(bool backlight_quirks) +int acpi_video_register(void) { - bool no_backlight; - int result; - - no_backlight = backlight_quirks ? acpi_video_backlight_quirks() : false; - + int result = 0; if (register_count) { /* - * If acpi_video_register() has been called already, don't try - * to register acpi_video_bus, but unregister backlight devices - * if no backlight support is requested. + * if the function of acpi_video_register is already called, + * don't register the acpi_vide_bus again and return no error. */ - if (no_backlight) - acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT, - ACPI_UINT32_MAX, - video_unregister_backlight, - NULL, NULL, NULL); - return 0; } @@ -1948,7 +1897,7 @@ int __acpi_video_register(bool backlight return 0; } -EXPORT_SYMBOL(__acpi_video_register); +EXPORT_SYMBOL(acpi_video_register); void acpi_video_unregister(void) { Index: linux-pm/drivers/gpu/drm/i915/i915_dma.c =================================================================== --- linux-pm.orig/drivers/gpu/drm/i915/i915_dma.c +++ linux-pm/drivers/gpu/drm/i915/i915_dma.c @@ -1648,7 +1648,7 @@ int i915_driver_load(struct drm_device * if (INTEL_INFO(dev)->num_pipes) { /* Must be done after probing outputs */ intel_opregion_init(dev); - acpi_video_register_with_quirks(); + acpi_video_register(); } if (IS_GEN5(dev)) Index: linux-pm/include/acpi/video.h =================================================================== --- linux-pm.orig/include/acpi/video.h +++ linux-pm/include/acpi/video.h @@ -17,21 +17,12 @@ struct acpi_device; #define ACPI_VIDEO_DISPLAY_LEGACY_TV 0x0200 #if (defined CONFIG_ACPI_VIDEO || defined CONFIG_ACPI_VIDEO_MODULE) -extern int __acpi_video_register(bool backlight_quirks); -static inline int acpi_video_register(void) -{ - return __acpi_video_register(false); -} -static inline int acpi_video_register_with_quirks(void) -{ - return __acpi_video_register(true); -} +extern int acpi_video_register(void); extern void acpi_video_unregister(void); extern int acpi_video_get_edid(struct acpi_device *device, int type, int device_id, void **edid); #else static inline int acpi_video_register(void) { return 0; } -static inline int acpi_video_register_with_quirks(void) { return 0; } static inline void acpi_video_unregister(void) { return; } static inline int acpi_video_get_edid(struct acpi_device *device, int type, int device_id, void **edid) Index: linux-pm/drivers/acpi/video_detect.c =================================================================== --- linux-pm.orig/drivers/acpi/video_detect.c +++ linux-pm/drivers/acpi/video_detect.c @@ -235,12 +235,7 @@ static void acpi_video_caps_check(void) bool acpi_video_backlight_quirks(void) { - if (acpi_gbl_osi_data >= ACPI_OSI_WIN_8) { - acpi_video_caps_check(); - acpi_video_support |= ACPI_VIDEO_SKIP_BACKLIGHT; - return true; - } - return false; + return acpi_gbl_osi_data >= ACPI_OSI_WIN_8; } EXPORT_SYMBOL(acpi_video_backlight_quirks); @@ -288,14 +283,6 @@ int acpi_video_backlight_support(void) } EXPORT_SYMBOL(acpi_video_backlight_support); -/* For the ACPI video driver use only. */ -bool acpi_video_verify_backlight_support(void) -{ - return (acpi_video_support & ACPI_VIDEO_SKIP_BACKLIGHT) ? - false : acpi_video_backlight_support(); -} -EXPORT_SYMBOL(acpi_video_verify_backlight_support); - /* * Use acpi_backlight=vendor/video to force that backlight switching * is processed by vendor specific acpi drivers or video.ko driver. Index: linux-pm/include/linux/acpi.h =================================================================== --- linux-pm.orig/include/linux/acpi.h +++ linux-pm/include/linux/acpi.h @@ -191,7 +191,6 @@ extern bool wmi_has_guid(const char *gui #define ACPI_VIDEO_BACKLIGHT_DMI_VIDEO 0x0200 #define ACPI_VIDEO_OUTPUT_SWITCHING_DMI_VENDOR 0x0400 #define ACPI_VIDEO_OUTPUT_SWITCHING_DMI_VIDEO 0x0800 -#define ACPI_VIDEO_SKIP_BACKLIGHT 0x1000 #if defined(CONFIG_ACPI_VIDEO) || defined(CONFIG_ACPI_VIDEO_MODULE) Index: linux-pm/drivers/acpi/internal.h =================================================================== --- linux-pm.orig/drivers/acpi/internal.h +++ linux-pm/drivers/acpi/internal.h @@ -169,10 +169,8 @@ int acpi_create_platform_device(struct a -------------------------------------------------------------------------- */ #if defined(CONFIG_ACPI_VIDEO) || defined(CONFIG_ACPI_VIDEO_MODULE) bool acpi_video_backlight_quirks(void); -bool acpi_video_verify_backlight_support(void); #else static inline bool acpi_video_backlight_quirks(void) { return false; } -static inline bool acpi_video_verify_backlight_support(void) { return false; } #endif #endif /* _ACPI_INTERNAL_H_ */ -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight, revert) @ 2013-07-25 13:00 ` Rafael J. Wysocki 0 siblings, 0 replies; 71+ messages in thread From: Rafael J. Wysocki @ 2013-07-25 13:00 UTC (permalink / raw) To: James Hogan, Kamal Mostafa, Aaron Lu, Kalle Valo Cc: Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, Steven Newbury, ACPI Devel Maling List, Jörg Otte, Martin Steigerwald, Daniel Vetter, intel-gfx, Jani Nikula On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote: > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote: > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > > > > > Linus, do you want me to send a pull request reverting 8c5bd7a and efaa14c? > > > > Yes, but let's wait a while. Not because I think we'll fix the problem > > (hey, miracles might happen), but because I think it would be useful > > to couple the reverts with information about the particular machines > > that broke (and the people who reported it). So that when we > > inevitably try again, we can perhaps get some testing effort with > > those machines/people. > > > > It doesn't seem to be a show-stopped for a large number of people, so > > there's no huge hurry. I'd suggest doing the revert just in time for > > rc3, but waiting until then to gather info about people who see > > breakage. > > > > Sound like a plan? > > Yes, it does. OK, time to revert I guess. James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended patch fixes the backlight for you. Aaron, please double check if acpi_video_backlight_quirks() will still work as needed. Thanks, Rafael --- From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Subject: Revert "ACPI / video / i915: No ACPI backlight if firmware expects Windows 8" We attempted to address a regression introduced by commit a57f7f9 (ACPICA: Add Windows8/Server2012 string for _OSI method.) after which ACPI video backlight support doesn't work on a number of systems, because the relevant AML methods in the ACPI tables in their BIOSes become useless after the BIOS has been told that the OS is compatible with Windows 8. That problem is tracked by the bug entry at: https://bugzilla.kernel.org/show_bug.cgi?id=51231 Commit 8c5bd7a (ACPI / video / i915: No ACPI backlight if firmware expects Windows 8) introduced for this purpose essentially prevented the ACPI backlight support from being used if the BIOS had been told that the OS was compatible with Windows 8 and the i915 driver was loaded, in which case the backlight would always be handled by i915. Unfortunately, however, that turned out to cause problems with backlight to appear on multiple systems with symptoms indicating that i915 was unable to control the backlight on those systems as expected. For this reason, revert commit 8c5bd7a, but leave the function acpi_video_backlight_quirks() introduced by it, because another commit on top of it uses that function. References: https://lkml.org/lkml/2013/7/21/119 References: https://lkml.org/lkml/2013/7/22/261 References: https://lkml.org/lkml/2013/7/23/429 References: https://lkml.org/lkml/2013/7/23/459 References: https://lkml.org/lkml/2013/7/23/81 References: https://lkml.org/lkml/2013/7/24/27 Reported-by: James Hogan <james@albanarts.com> Reported-by: Steven Newbury <steve@snewbury.org.uk> Reported-by: Kamal Mostafa <kamal@canonical.com> Reported-by: Martin Steigerwald <Martin@lichtvoll.de> Reported-by: Jörg Otte <jrg.otte@gmail.com> Reported-by: Kalle Valo <kvalo@adurom.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> --- drivers/acpi/internal.h | 2 - drivers/acpi/video.c | 67 ++++------------------------------------ drivers/acpi/video_detect.c | 15 -------- drivers/gpu/drm/i915/i915_dma.c | 2 - include/acpi/video.h | 11 ------ include/linux/acpi.h | 1 6 files changed, 11 insertions(+), 87 deletions(-) Index: linux-pm/drivers/acpi/video.c =================================================================== --- linux-pm.orig/drivers/acpi/video.c +++ linux-pm/drivers/acpi/video.c @@ -897,7 +897,7 @@ static void acpi_video_device_find_cap(s if (acpi_video_init_brightness(device)) return; - if (acpi_video_verify_backlight_support()) { + if (acpi_video_backlight_support()) { struct backlight_properties props; struct pci_dev *pdev; acpi_handle acpi_parent; @@ -1344,8 +1344,8 @@ acpi_video_switch_brightness(struct acpi unsigned long long level_current, level_next; int result = -EINVAL; - /* no warning message if acpi_backlight=vendor or a quirk is used */ - if (!acpi_video_verify_backlight_support()) + /* no warning message if acpi_backlight=vendor is used */ + if (!acpi_video_backlight_support()) return 0; if (!device->brightness) @@ -1843,46 +1843,6 @@ static int acpi_video_bus_remove(struct return 0; } -static acpi_status video_unregister_backlight(acpi_handle handle, u32 lvl, - void *context, void **rv) -{ - struct acpi_device *acpi_dev; - struct acpi_video_bus *video; - struct acpi_video_device *dev, *next; - - if (acpi_bus_get_device(handle, &acpi_dev)) - return AE_OK; - - if (acpi_match_device_ids(acpi_dev, video_device_ids)) - return AE_OK; - - video = acpi_driver_data(acpi_dev); - if (!video) - return AE_OK; - - acpi_video_bus_stop_devices(video); - mutex_lock(&video->device_list_lock); - list_for_each_entry_safe(dev, next, &video->video_device_list, entry) { - if (dev->backlight) { - backlight_device_unregister(dev->backlight); - dev->backlight = NULL; - kfree(dev->brightness->levels); - kfree(dev->brightness); - } - if (dev->cooling_dev) { - sysfs_remove_link(&dev->dev->dev.kobj, - "thermal_cooling"); - sysfs_remove_link(&dev->cooling_dev->device.kobj, - "device"); - thermal_cooling_device_unregister(dev->cooling_dev); - dev->cooling_dev = NULL; - } - } - mutex_unlock(&video->device_list_lock); - acpi_video_bus_start_devices(video); - return AE_OK; -} - static int __init is_i740(struct pci_dev *dev) { if (dev->device == 0x00D1) @@ -1914,25 +1874,14 @@ static int __init intel_opregion_present return opregion; } -int __acpi_video_register(bool backlight_quirks) +int acpi_video_register(void) { - bool no_backlight; - int result; - - no_backlight = backlight_quirks ? acpi_video_backlight_quirks() : false; - + int result = 0; if (register_count) { /* - * If acpi_video_register() has been called already, don't try - * to register acpi_video_bus, but unregister backlight devices - * if no backlight support is requested. + * if the function of acpi_video_register is already called, + * don't register the acpi_vide_bus again and return no error. */ - if (no_backlight) - acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT, - ACPI_UINT32_MAX, - video_unregister_backlight, - NULL, NULL, NULL); - return 0; } @@ -1948,7 +1897,7 @@ int __acpi_video_register(bool backlight return 0; } -EXPORT_SYMBOL(__acpi_video_register); +EXPORT_SYMBOL(acpi_video_register); void acpi_video_unregister(void) { Index: linux-pm/drivers/gpu/drm/i915/i915_dma.c =================================================================== --- linux-pm.orig/drivers/gpu/drm/i915/i915_dma.c +++ linux-pm/drivers/gpu/drm/i915/i915_dma.c @@ -1648,7 +1648,7 @@ int i915_driver_load(struct drm_device * if (INTEL_INFO(dev)->num_pipes) { /* Must be done after probing outputs */ intel_opregion_init(dev); - acpi_video_register_with_quirks(); + acpi_video_register(); } if (IS_GEN5(dev)) Index: linux-pm/include/acpi/video.h =================================================================== --- linux-pm.orig/include/acpi/video.h +++ linux-pm/include/acpi/video.h @@ -17,21 +17,12 @@ struct acpi_device; #define ACPI_VIDEO_DISPLAY_LEGACY_TV 0x0200 #if (defined CONFIG_ACPI_VIDEO || defined CONFIG_ACPI_VIDEO_MODULE) -extern int __acpi_video_register(bool backlight_quirks); -static inline int acpi_video_register(void) -{ - return __acpi_video_register(false); -} -static inline int acpi_video_register_with_quirks(void) -{ - return __acpi_video_register(true); -} +extern int acpi_video_register(void); extern void acpi_video_unregister(void); extern int acpi_video_get_edid(struct acpi_device *device, int type, int device_id, void **edid); #else static inline int acpi_video_register(void) { return 0; } -static inline int acpi_video_register_with_quirks(void) { return 0; } static inline void acpi_video_unregister(void) { return; } static inline int acpi_video_get_edid(struct acpi_device *device, int type, int device_id, void **edid) Index: linux-pm/drivers/acpi/video_detect.c =================================================================== --- linux-pm.orig/drivers/acpi/video_detect.c +++ linux-pm/drivers/acpi/video_detect.c @@ -235,12 +235,7 @@ static void acpi_video_caps_check(void) bool acpi_video_backlight_quirks(void) { - if (acpi_gbl_osi_data >= ACPI_OSI_WIN_8) { - acpi_video_caps_check(); - acpi_video_support |= ACPI_VIDEO_SKIP_BACKLIGHT; - return true; - } - return false; + return acpi_gbl_osi_data >= ACPI_OSI_WIN_8; } EXPORT_SYMBOL(acpi_video_backlight_quirks); @@ -288,14 +283,6 @@ int acpi_video_backlight_support(void) } EXPORT_SYMBOL(acpi_video_backlight_support); -/* For the ACPI video driver use only. */ -bool acpi_video_verify_backlight_support(void) -{ - return (acpi_video_support & ACPI_VIDEO_SKIP_BACKLIGHT) ? - false : acpi_video_backlight_support(); -} -EXPORT_SYMBOL(acpi_video_verify_backlight_support); - /* * Use acpi_backlight=vendor/video to force that backlight switching * is processed by vendor specific acpi drivers or video.ko driver. Index: linux-pm/include/linux/acpi.h =================================================================== --- linux-pm.orig/include/linux/acpi.h +++ linux-pm/include/linux/acpi.h @@ -191,7 +191,6 @@ extern bool wmi_has_guid(const char *gui #define ACPI_VIDEO_BACKLIGHT_DMI_VIDEO 0x0200 #define ACPI_VIDEO_OUTPUT_SWITCHING_DMI_VENDOR 0x0400 #define ACPI_VIDEO_OUTPUT_SWITCHING_DMI_VIDEO 0x0800 -#define ACPI_VIDEO_SKIP_BACKLIGHT 0x1000 #if defined(CONFIG_ACPI_VIDEO) || defined(CONFIG_ACPI_VIDEO_MODULE) Index: linux-pm/drivers/acpi/internal.h =================================================================== --- linux-pm.orig/drivers/acpi/internal.h +++ linux-pm/drivers/acpi/internal.h @@ -169,10 +169,8 @@ int acpi_create_platform_device(struct a -------------------------------------------------------------------------- */ #if defined(CONFIG_ACPI_VIDEO) || defined(CONFIG_ACPI_VIDEO_MODULE) bool acpi_video_backlight_quirks(void); -bool acpi_video_verify_backlight_support(void); #else static inline bool acpi_video_backlight_quirks(void) { return false; } -static inline bool acpi_video_verify_backlight_support(void) { return false; } #endif #endif /* _ACPI_INTERNAL_H_ */ ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight, revert) 2013-07-25 13:00 ` Rafael J. Wysocki (?) @ 2013-07-25 14:13 ` Aaron Lu -1 siblings, 0 replies; 71+ messages in thread From: Aaron Lu @ 2013-07-25 14:13 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Matthew Garrett, James Hogan, Martin Steigerwald, Daniel Vetter, Rafael J. Wysocki, Linux Kernel Mailing List, ACPI Devel Maling List, Jörg Otte, intel-gfx, Linus Torvalds, Kalle Valo [-- Attachment #1.1: Type: text/plain, Size: 12857 bytes --] On Thu, Jul 25, 2013 at 9:00 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote: > > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote: > > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <rjw@sisk.pl> > wrote: > > > > > > > > Linus, do you want me to send a pull request reverting 8c5bd7a and > efaa14c? > > > > > > Yes, but let's wait a while. Not because I think we'll fix the problem > > > (hey, miracles might happen), but because I think it would be useful > > > to couple the reverts with information about the particular machines > > > that broke (and the people who reported it). So that when we > > > inevitably try again, we can perhaps get some testing effort with > > > those machines/people. > > > > > > It doesn't seem to be a show-stopped for a large number of people, so > > > there's no huge hurry. I'd suggest doing the revert just in time for > > > rc3, but waiting until then to gather info about people who see > > > breakage. > > > > > > Sound like a plan? > > > > Yes, it does. > > OK, time to revert I guess. > > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended > patch > fixes the backlight for you. > > Aaron, please double check if acpi_video_backlight_quirks() will still > work as > needed. > Yes, I think so. Thanks, Aaron > > Thanks, > Rafael > > > --- > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > Subject: Revert "ACPI / video / i915: No ACPI backlight if firmware > expects Windows 8" > > We attempted to address a regression introduced by commit a57f7f9 > (ACPICA: Add Windows8/Server2012 string for _OSI method.) after which > ACPI video backlight support doesn't work on a number of systems, > because the relevant AML methods in the ACPI tables in their BIOSes > become useless after the BIOS has been told that the OS is compatible > with Windows 8. That problem is tracked by the bug entry at: > > https://bugzilla.kernel.org/show_bug.cgi?id=51231 > > Commit 8c5bd7a (ACPI / video / i915: No ACPI backlight if firmware > expects Windows 8) introduced for this purpose essentially prevented > the ACPI backlight support from being used if the BIOS had been told > that the OS was compatible with Windows 8 and the i915 driver was > loaded, in which case the backlight would always be handled by i915. > Unfortunately, however, that turned out to cause problems with > backlight to appear on multiple systems with symptoms indicating that > i915 was unable to control the backlight on those systems as > expected. > > For this reason, revert commit 8c5bd7a, but leave the function > acpi_video_backlight_quirks() introduced by it, because another > commit on top of it uses that function. > > References: https://lkml.org/lkml/2013/7/21/119 > References: https://lkml.org/lkml/2013/7/22/261 > References: https://lkml.org/lkml/2013/7/23/429 > References: https://lkml.org/lkml/2013/7/23/459 > References: https://lkml.org/lkml/2013/7/23/81 > References: https://lkml.org/lkml/2013/7/24/27 > Reported-by: James Hogan <james@albanarts.com> > Reported-by: Steven Newbury <steve@snewbury.org.uk> > Reported-by: Kamal Mostafa <kamal@canonical.com> > Reported-by: Martin Steigerwald <Martin@lichtvoll.de> > Reported-by: Jörg Otte <jrg.otte@gmail.com> > Reported-by: Kalle Valo <kvalo@adurom.com> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > --- > drivers/acpi/internal.h | 2 - > drivers/acpi/video.c | 67 > ++++------------------------------------ > drivers/acpi/video_detect.c | 15 -------- > drivers/gpu/drm/i915/i915_dma.c | 2 - > include/acpi/video.h | 11 ------ > include/linux/acpi.h | 1 > 6 files changed, 11 insertions(+), 87 deletions(-) > > Index: linux-pm/drivers/acpi/video.c > =================================================================== > --- linux-pm.orig/drivers/acpi/video.c > +++ linux-pm/drivers/acpi/video.c > @@ -897,7 +897,7 @@ static void acpi_video_device_find_cap(s > if (acpi_video_init_brightness(device)) > return; > > - if (acpi_video_verify_backlight_support()) { > + if (acpi_video_backlight_support()) { > struct backlight_properties props; > struct pci_dev *pdev; > acpi_handle acpi_parent; > @@ -1344,8 +1344,8 @@ acpi_video_switch_brightness(struct acpi > unsigned long long level_current, level_next; > int result = -EINVAL; > > - /* no warning message if acpi_backlight=vendor or a quirk is used > */ > - if (!acpi_video_verify_backlight_support()) > + /* no warning message if acpi_backlight=vendor is used */ > + if (!acpi_video_backlight_support()) > return 0; > > if (!device->brightness) > @@ -1843,46 +1843,6 @@ static int acpi_video_bus_remove(struct > return 0; > } > > -static acpi_status video_unregister_backlight(acpi_handle handle, u32 lvl, > - void *context, void **rv) > -{ > - struct acpi_device *acpi_dev; > - struct acpi_video_bus *video; > - struct acpi_video_device *dev, *next; > - > - if (acpi_bus_get_device(handle, &acpi_dev)) > - return AE_OK; > - > - if (acpi_match_device_ids(acpi_dev, video_device_ids)) > - return AE_OK; > - > - video = acpi_driver_data(acpi_dev); > - if (!video) > - return AE_OK; > - > - acpi_video_bus_stop_devices(video); > - mutex_lock(&video->device_list_lock); > - list_for_each_entry_safe(dev, next, &video->video_device_list, > entry) { > - if (dev->backlight) { > - backlight_device_unregister(dev->backlight); > - dev->backlight = NULL; > - kfree(dev->brightness->levels); > - kfree(dev->brightness); > - } > - if (dev->cooling_dev) { > - sysfs_remove_link(&dev->dev->dev.kobj, > - "thermal_cooling"); > - sysfs_remove_link(&dev->cooling_dev->device.kobj, > - "device"); > - > thermal_cooling_device_unregister(dev->cooling_dev); > - dev->cooling_dev = NULL; > - } > - } > - mutex_unlock(&video->device_list_lock); > - acpi_video_bus_start_devices(video); > - return AE_OK; > -} > - > static int __init is_i740(struct pci_dev *dev) > { > if (dev->device == 0x00D1) > @@ -1914,25 +1874,14 @@ static int __init intel_opregion_present > return opregion; > } > > -int __acpi_video_register(bool backlight_quirks) > +int acpi_video_register(void) > { > - bool no_backlight; > - int result; > - > - no_backlight = backlight_quirks ? acpi_video_backlight_quirks() : > false; > - > + int result = 0; > if (register_count) { > /* > - * If acpi_video_register() has been called already, don't > try > - * to register acpi_video_bus, but unregister backlight > devices > - * if no backlight support is requested. > + * if the function of acpi_video_register is already > called, > + * don't register the acpi_vide_bus again and return no > error. > */ > - if (no_backlight) > - acpi_walk_namespace(ACPI_TYPE_DEVICE, > ACPI_ROOT_OBJECT, > - ACPI_UINT32_MAX, > - video_unregister_backlight, > - NULL, NULL, NULL); > - > return 0; > } > > @@ -1948,7 +1897,7 @@ int __acpi_video_register(bool backlight > > return 0; > } > -EXPORT_SYMBOL(__acpi_video_register); > +EXPORT_SYMBOL(acpi_video_register); > > void acpi_video_unregister(void) > { > Index: linux-pm/drivers/gpu/drm/i915/i915_dma.c > =================================================================== > --- linux-pm.orig/drivers/gpu/drm/i915/i915_dma.c > +++ linux-pm/drivers/gpu/drm/i915/i915_dma.c > @@ -1648,7 +1648,7 @@ int i915_driver_load(struct drm_device * > if (INTEL_INFO(dev)->num_pipes) { > /* Must be done after probing outputs */ > intel_opregion_init(dev); > - acpi_video_register_with_quirks(); > + acpi_video_register(); > } > > if (IS_GEN5(dev)) > Index: linux-pm/include/acpi/video.h > =================================================================== > --- linux-pm.orig/include/acpi/video.h > +++ linux-pm/include/acpi/video.h > @@ -17,21 +17,12 @@ struct acpi_device; > #define ACPI_VIDEO_DISPLAY_LEGACY_TV 0x0200 > > #if (defined CONFIG_ACPI_VIDEO || defined CONFIG_ACPI_VIDEO_MODULE) > -extern int __acpi_video_register(bool backlight_quirks); > -static inline int acpi_video_register(void) > -{ > - return __acpi_video_register(false); > -} > -static inline int acpi_video_register_with_quirks(void) > -{ > - return __acpi_video_register(true); > -} > +extern int acpi_video_register(void); > extern void acpi_video_unregister(void); > extern int acpi_video_get_edid(struct acpi_device *device, int type, > int device_id, void **edid); > #else > static inline int acpi_video_register(void) { return 0; } > -static inline int acpi_video_register_with_quirks(void) { return 0; } > static inline void acpi_video_unregister(void) { return; } > static inline int acpi_video_get_edid(struct acpi_device *device, int > type, > int device_id, void **edid) > Index: linux-pm/drivers/acpi/video_detect.c > =================================================================== > --- linux-pm.orig/drivers/acpi/video_detect.c > +++ linux-pm/drivers/acpi/video_detect.c > @@ -235,12 +235,7 @@ static void acpi_video_caps_check(void) > > bool acpi_video_backlight_quirks(void) > { > - if (acpi_gbl_osi_data >= ACPI_OSI_WIN_8) { > - acpi_video_caps_check(); > - acpi_video_support |= ACPI_VIDEO_SKIP_BACKLIGHT; > - return true; > - } > - return false; > + return acpi_gbl_osi_data >= ACPI_OSI_WIN_8; > } > EXPORT_SYMBOL(acpi_video_backlight_quirks); > > @@ -288,14 +283,6 @@ int acpi_video_backlight_support(void) > } > EXPORT_SYMBOL(acpi_video_backlight_support); > > -/* For the ACPI video driver use only. */ > -bool acpi_video_verify_backlight_support(void) > -{ > - return (acpi_video_support & ACPI_VIDEO_SKIP_BACKLIGHT) ? > - false : acpi_video_backlight_support(); > -} > -EXPORT_SYMBOL(acpi_video_verify_backlight_support); > - > /* > * Use acpi_backlight=vendor/video to force that backlight switching > * is processed by vendor specific acpi drivers or video.ko driver. > Index: linux-pm/include/linux/acpi.h > =================================================================== > --- linux-pm.orig/include/linux/acpi.h > +++ linux-pm/include/linux/acpi.h > @@ -191,7 +191,6 @@ extern bool wmi_has_guid(const char *gui > #define ACPI_VIDEO_BACKLIGHT_DMI_VIDEO 0x0200 > #define ACPI_VIDEO_OUTPUT_SWITCHING_DMI_VENDOR 0x0400 > #define ACPI_VIDEO_OUTPUT_SWITCHING_DMI_VIDEO 0x0800 > -#define ACPI_VIDEO_SKIP_BACKLIGHT 0x1000 > > #if defined(CONFIG_ACPI_VIDEO) || defined(CONFIG_ACPI_VIDEO_MODULE) > > Index: linux-pm/drivers/acpi/internal.h > =================================================================== > --- linux-pm.orig/drivers/acpi/internal.h > +++ linux-pm/drivers/acpi/internal.h > @@ -169,10 +169,8 @@ int acpi_create_platform_device(struct a > > -------------------------------------------------------------------------- > */ > #if defined(CONFIG_ACPI_VIDEO) || defined(CONFIG_ACPI_VIDEO_MODULE) > bool acpi_video_backlight_quirks(void); > -bool acpi_video_verify_backlight_support(void); > #else > static inline bool acpi_video_backlight_quirks(void) { return false; } > -static inline bool acpi_video_verify_backlight_support(void) { return > false; } > #endif > > #endif /* _ACPI_INTERNAL_H_ */ > > -- > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > [-- Attachment #1.2: Type: text/html, Size: 15219 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight, revert) 2013-07-25 13:00 ` Rafael J. Wysocki (?) (?) @ 2013-07-25 14:43 ` Kamal Mostafa 2013-07-25 14:46 ` Daniel Vetter -1 siblings, 1 reply; 71+ messages in thread From: Kamal Mostafa @ 2013-07-25 14:43 UTC (permalink / raw) To: Rafael J. Wysocki Cc: James Hogan, Aaron Lu, Kalle Valo, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, Steven Newbury, ACPI Devel Maling List, Jörg Otte, Martin Steigerwald, Daniel Vetter, intel-gfx, Jani Nikula [-- Attachment #1: Type: text/plain, Size: 11597 bytes --] On Thu, 2013-07-25 at 15:00 +0200, Rafael J. Wysocki wrote: > On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote: > > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote: > > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > > > > > > > Linus, do you want me to send a pull request reverting 8c5bd7a and efaa14c? > > > > > > Yes, but let's wait a while. Not because I think we'll fix the problem > > > (hey, miracles might happen), but because I think it would be useful > > > to couple the reverts with information about the particular machines > > > that broke (and the people who reported it). So that when we > > > inevitably try again, we can perhaps get some testing effort with > > > those machines/people. > > > > > > It doesn't seem to be a show-stopped for a large number of people, so > > > there's no huge hurry. I'd suggest doing the revert just in time for > > > rc3, but waiting until then to gather info about people who see > > > breakage. > > > > > > Sound like a plan? > > > > Yes, it does. > > OK, time to revert I guess. > > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended patch > fixes the backlight for you. Yes, this revert patch does re-enable backlight control for the affected Dell XPS13 models. -Kamal > Aaron, please double check if acpi_video_backlight_quirks() will still work as > needed. > > Thanks, > Rafael > > > --- > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > Subject: Revert "ACPI / video / i915: No ACPI backlight if firmware expects Windows 8" > > We attempted to address a regression introduced by commit a57f7f9 > (ACPICA: Add Windows8/Server2012 string for _OSI method.) after which > ACPI video backlight support doesn't work on a number of systems, > because the relevant AML methods in the ACPI tables in their BIOSes > become useless after the BIOS has been told that the OS is compatible > with Windows 8. That problem is tracked by the bug entry at: > > https://bugzilla.kernel.org/show_bug.cgi?id=51231 > > Commit 8c5bd7a (ACPI / video / i915: No ACPI backlight if firmware > expects Windows 8) introduced for this purpose essentially prevented > the ACPI backlight support from being used if the BIOS had been told > that the OS was compatible with Windows 8 and the i915 driver was > loaded, in which case the backlight would always be handled by i915. > Unfortunately, however, that turned out to cause problems with > backlight to appear on multiple systems with symptoms indicating that > i915 was unable to control the backlight on those systems as > expected. > > For this reason, revert commit 8c5bd7a, but leave the function > acpi_video_backlight_quirks() introduced by it, because another > commit on top of it uses that function. > > References: https://lkml.org/lkml/2013/7/21/119 > References: https://lkml.org/lkml/2013/7/22/261 > References: https://lkml.org/lkml/2013/7/23/429 > References: https://lkml.org/lkml/2013/7/23/459 > References: https://lkml.org/lkml/2013/7/23/81 > References: https://lkml.org/lkml/2013/7/24/27 > Reported-by: James Hogan <james@albanarts.com> > Reported-by: Steven Newbury <steve@snewbury.org.uk> > Reported-by: Kamal Mostafa <kamal@canonical.com> > Reported-by: Martin Steigerwald <Martin@lichtvoll.de> > Reported-by: Jörg Otte <jrg.otte@gmail.com> > Reported-by: Kalle Valo <kvalo@adurom.com> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > --- > drivers/acpi/internal.h | 2 - > drivers/acpi/video.c | 67 ++++------------------------------------ > drivers/acpi/video_detect.c | 15 -------- > drivers/gpu/drm/i915/i915_dma.c | 2 - > include/acpi/video.h | 11 ------ > include/linux/acpi.h | 1 > 6 files changed, 11 insertions(+), 87 deletions(-) > > Index: linux-pm/drivers/acpi/video.c > =================================================================== > --- linux-pm.orig/drivers/acpi/video.c > +++ linux-pm/drivers/acpi/video.c > @@ -897,7 +897,7 @@ static void acpi_video_device_find_cap(s > if (acpi_video_init_brightness(device)) > return; > > - if (acpi_video_verify_backlight_support()) { > + if (acpi_video_backlight_support()) { > struct backlight_properties props; > struct pci_dev *pdev; > acpi_handle acpi_parent; > @@ -1344,8 +1344,8 @@ acpi_video_switch_brightness(struct acpi > unsigned long long level_current, level_next; > int result = -EINVAL; > > - /* no warning message if acpi_backlight=vendor or a quirk is used */ > - if (!acpi_video_verify_backlight_support()) > + /* no warning message if acpi_backlight=vendor is used */ > + if (!acpi_video_backlight_support()) > return 0; > > if (!device->brightness) > @@ -1843,46 +1843,6 @@ static int acpi_video_bus_remove(struct > return 0; > } > > -static acpi_status video_unregister_backlight(acpi_handle handle, u32 lvl, > - void *context, void **rv) > -{ > - struct acpi_device *acpi_dev; > - struct acpi_video_bus *video; > - struct acpi_video_device *dev, *next; > - > - if (acpi_bus_get_device(handle, &acpi_dev)) > - return AE_OK; > - > - if (acpi_match_device_ids(acpi_dev, video_device_ids)) > - return AE_OK; > - > - video = acpi_driver_data(acpi_dev); > - if (!video) > - return AE_OK; > - > - acpi_video_bus_stop_devices(video); > - mutex_lock(&video->device_list_lock); > - list_for_each_entry_safe(dev, next, &video->video_device_list, entry) { > - if (dev->backlight) { > - backlight_device_unregister(dev->backlight); > - dev->backlight = NULL; > - kfree(dev->brightness->levels); > - kfree(dev->brightness); > - } > - if (dev->cooling_dev) { > - sysfs_remove_link(&dev->dev->dev.kobj, > - "thermal_cooling"); > - sysfs_remove_link(&dev->cooling_dev->device.kobj, > - "device"); > - thermal_cooling_device_unregister(dev->cooling_dev); > - dev->cooling_dev = NULL; > - } > - } > - mutex_unlock(&video->device_list_lock); > - acpi_video_bus_start_devices(video); > - return AE_OK; > -} > - > static int __init is_i740(struct pci_dev *dev) > { > if (dev->device == 0x00D1) > @@ -1914,25 +1874,14 @@ static int __init intel_opregion_present > return opregion; > } > > -int __acpi_video_register(bool backlight_quirks) > +int acpi_video_register(void) > { > - bool no_backlight; > - int result; > - > - no_backlight = backlight_quirks ? acpi_video_backlight_quirks() : false; > - > + int result = 0; > if (register_count) { > /* > - * If acpi_video_register() has been called already, don't try > - * to register acpi_video_bus, but unregister backlight devices > - * if no backlight support is requested. > + * if the function of acpi_video_register is already called, > + * don't register the acpi_vide_bus again and return no error. > */ > - if (no_backlight) > - acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT, > - ACPI_UINT32_MAX, > - video_unregister_backlight, > - NULL, NULL, NULL); > - > return 0; > } > > @@ -1948,7 +1897,7 @@ int __acpi_video_register(bool backlight > > return 0; > } > -EXPORT_SYMBOL(__acpi_video_register); > +EXPORT_SYMBOL(acpi_video_register); > > void acpi_video_unregister(void) > { > Index: linux-pm/drivers/gpu/drm/i915/i915_dma.c > =================================================================== > --- linux-pm.orig/drivers/gpu/drm/i915/i915_dma.c > +++ linux-pm/drivers/gpu/drm/i915/i915_dma.c > @@ -1648,7 +1648,7 @@ int i915_driver_load(struct drm_device * > if (INTEL_INFO(dev)->num_pipes) { > /* Must be done after probing outputs */ > intel_opregion_init(dev); > - acpi_video_register_with_quirks(); > + acpi_video_register(); > } > > if (IS_GEN5(dev)) > Index: linux-pm/include/acpi/video.h > =================================================================== > --- linux-pm.orig/include/acpi/video.h > +++ linux-pm/include/acpi/video.h > @@ -17,21 +17,12 @@ struct acpi_device; > #define ACPI_VIDEO_DISPLAY_LEGACY_TV 0x0200 > > #if (defined CONFIG_ACPI_VIDEO || defined CONFIG_ACPI_VIDEO_MODULE) > -extern int __acpi_video_register(bool backlight_quirks); > -static inline int acpi_video_register(void) > -{ > - return __acpi_video_register(false); > -} > -static inline int acpi_video_register_with_quirks(void) > -{ > - return __acpi_video_register(true); > -} > +extern int acpi_video_register(void); > extern void acpi_video_unregister(void); > extern int acpi_video_get_edid(struct acpi_device *device, int type, > int device_id, void **edid); > #else > static inline int acpi_video_register(void) { return 0; } > -static inline int acpi_video_register_with_quirks(void) { return 0; } > static inline void acpi_video_unregister(void) { return; } > static inline int acpi_video_get_edid(struct acpi_device *device, int type, > int device_id, void **edid) > Index: linux-pm/drivers/acpi/video_detect.c > =================================================================== > --- linux-pm.orig/drivers/acpi/video_detect.c > +++ linux-pm/drivers/acpi/video_detect.c > @@ -235,12 +235,7 @@ static void acpi_video_caps_check(void) > > bool acpi_video_backlight_quirks(void) > { > - if (acpi_gbl_osi_data >= ACPI_OSI_WIN_8) { > - acpi_video_caps_check(); > - acpi_video_support |= ACPI_VIDEO_SKIP_BACKLIGHT; > - return true; > - } > - return false; > + return acpi_gbl_osi_data >= ACPI_OSI_WIN_8; > } > EXPORT_SYMBOL(acpi_video_backlight_quirks); > > @@ -288,14 +283,6 @@ int acpi_video_backlight_support(void) > } > EXPORT_SYMBOL(acpi_video_backlight_support); > > -/* For the ACPI video driver use only. */ > -bool acpi_video_verify_backlight_support(void) > -{ > - return (acpi_video_support & ACPI_VIDEO_SKIP_BACKLIGHT) ? > - false : acpi_video_backlight_support(); > -} > -EXPORT_SYMBOL(acpi_video_verify_backlight_support); > - > /* > * Use acpi_backlight=vendor/video to force that backlight switching > * is processed by vendor specific acpi drivers or video.ko driver. > Index: linux-pm/include/linux/acpi.h > =================================================================== > --- linux-pm.orig/include/linux/acpi.h > +++ linux-pm/include/linux/acpi.h > @@ -191,7 +191,6 @@ extern bool wmi_has_guid(const char *gui > #define ACPI_VIDEO_BACKLIGHT_DMI_VIDEO 0x0200 > #define ACPI_VIDEO_OUTPUT_SWITCHING_DMI_VENDOR 0x0400 > #define ACPI_VIDEO_OUTPUT_SWITCHING_DMI_VIDEO 0x0800 > -#define ACPI_VIDEO_SKIP_BACKLIGHT 0x1000 > > #if defined(CONFIG_ACPI_VIDEO) || defined(CONFIG_ACPI_VIDEO_MODULE) > > Index: linux-pm/drivers/acpi/internal.h > =================================================================== > --- linux-pm.orig/drivers/acpi/internal.h > +++ linux-pm/drivers/acpi/internal.h > @@ -169,10 +169,8 @@ int acpi_create_platform_device(struct a > -------------------------------------------------------------------------- */ > #if defined(CONFIG_ACPI_VIDEO) || defined(CONFIG_ACPI_VIDEO_MODULE) > bool acpi_video_backlight_quirks(void); > -bool acpi_video_verify_backlight_support(void); > #else > static inline bool acpi_video_backlight_quirks(void) { return false; } > -static inline bool acpi_video_verify_backlight_support(void) { return false; } > #endif > > #endif /* _ACPI_INTERNAL_H_ */ > [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight, revert) 2013-07-25 14:43 ` Kamal Mostafa @ 2013-07-25 14:46 ` Daniel Vetter 0 siblings, 0 replies; 71+ messages in thread From: Daniel Vetter @ 2013-07-25 14:46 UTC (permalink / raw) To: Kamal Mostafa Cc: Rafael J. Wysocki, James Hogan, Aaron Lu, Kalle Valo, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, Steven Newbury, ACPI Devel Maling List, Jörg Otte, Martin Steigerwald, Daniel Vetter, intel-gfx, Jani Nikula On Thu, Jul 25, 2013 at 07:43:17AM -0700, Kamal Mostafa wrote: > On Thu, 2013-07-25 at 15:00 +0200, Rafael J. Wysocki wrote: > > On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote: > > > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote: > > > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > > > > > > > > > Linus, do you want me to send a pull request reverting 8c5bd7a and efaa14c? > > > > > > > > Yes, but let's wait a while. Not because I think we'll fix the problem > > > > (hey, miracles might happen), but because I think it would be useful > > > > to couple the reverts with information about the particular machines > > > > that broke (and the people who reported it). So that when we > > > > inevitably try again, we can perhaps get some testing effort with > > > > those machines/people. > > > > > > > > It doesn't seem to be a show-stopped for a large number of people, so > > > > there's no huge hurry. I'd suggest doing the revert just in time for > > > > rc3, but waiting until then to gather info about people who see > > > > breakage. > > > > > > > > Sound like a plan? > > > > > > Yes, it does. > > > > OK, time to revert I guess. > > > > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended patch > > fixes the backlight for you. > > Yes, this revert patch does re-enable backlight control for the affected > Dell XPS13 models. Are these the same models that neeed the special quirk to not write PCH_PWM_ENABLE? Or do they need both? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight, revert) @ 2013-07-25 14:46 ` Daniel Vetter 0 siblings, 0 replies; 71+ messages in thread From: Daniel Vetter @ 2013-07-25 14:46 UTC (permalink / raw) To: Kamal Mostafa Cc: Rafael J. Wysocki, James Hogan, Aaron Lu, Kalle Valo, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, Steven Newbury, ACPI Devel Maling List, Jörg Otte, Martin Steigerwald, Daniel Vetter, intel-gfx, Jani Nikula On Thu, Jul 25, 2013 at 07:43:17AM -0700, Kamal Mostafa wrote: > On Thu, 2013-07-25 at 15:00 +0200, Rafael J. Wysocki wrote: > > On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote: > > > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote: > > > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > > > > > > > > > Linus, do you want me to send a pull request reverting 8c5bd7a and efaa14c? > > > > > > > > Yes, but let's wait a while. Not because I think we'll fix the problem > > > > (hey, miracles might happen), but because I think it would be useful > > > > to couple the reverts with information about the particular machines > > > > that broke (and the people who reported it). So that when we > > > > inevitably try again, we can perhaps get some testing effort with > > > > those machines/people. > > > > > > > > It doesn't seem to be a show-stopped for a large number of people, so > > > > there's no huge hurry. I'd suggest doing the revert just in time for > > > > rc3, but waiting until then to gather info about people who see > > > > breakage. > > > > > > > > Sound like a plan? > > > > > > Yes, it does. > > > > OK, time to revert I guess. > > > > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended patch > > fixes the backlight for you. > > Yes, this revert patch does re-enable backlight control for the affected > Dell XPS13 models. Are these the same models that neeed the special quirk to not write PCH_PWM_ENABLE? Or do they need both? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight, revert) 2013-07-25 14:46 ` Daniel Vetter (?) @ 2013-07-25 14:59 ` Kamal Mostafa -1 siblings, 0 replies; 71+ messages in thread From: Kamal Mostafa @ 2013-07-25 14:59 UTC (permalink / raw) To: Daniel Vetter Cc: Rafael J. Wysocki, James Hogan, Aaron Lu, Kalle Valo, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, Steven Newbury, ACPI Devel Maling List, Jörg Otte, Martin Steigerwald, Daniel Vetter, intel-gfx, Jani Nikula [-- Attachment #1: Type: text/plain, Size: 2181 bytes --] On Thu, 2013-07-25 at 16:46 +0200, Daniel Vetter wrote: > On Thu, Jul 25, 2013 at 07:43:17AM -0700, Kamal Mostafa wrote: > > On Thu, 2013-07-25 at 15:00 +0200, Rafael J. Wysocki wrote: > > > On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote: > > > > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote: > > > > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > > > > > > > > > > > Linus, do you want me to send a pull request reverting 8c5bd7a and efaa14c? > > > > > > > > > > Yes, but let's wait a while. Not because I think we'll fix the problem > > > > > (hey, miracles might happen), but because I think it would be useful > > > > > to couple the reverts with information about the particular machines > > > > > that broke (and the people who reported it). So that when we > > > > > inevitably try again, we can perhaps get some testing effort with > > > > > those machines/people. > > > > > > > > > > It doesn't seem to be a show-stopped for a large number of people, so > > > > > there's no huge hurry. I'd suggest doing the revert just in time for > > > > > rc3, but waiting until then to gather info about people who see > > > > > breakage. > > > > > > > > > > Sound like a plan? > > > > > > > > Yes, it does. > > > > > > OK, time to revert I guess. > > > > > > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended patch > > > fixes the backlight for you. > > > > Yes, this revert patch does re-enable backlight control for the affected > > Dell XPS13 models. > > Are these the same models that neeed the special quirk to not write > PCH_PWM_ENABLE? Or do they need both? Hi Daniel- Yes, these are the same models (Dell XPS13) that need the PCH_PWM_ENABLE quirk, but that's not related to this ACPI problem... All of the XPS13 models still need the PCH_PWM_ENABLE quirk which is now present in mainline (e85843b "drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight"). Separately from that, some of the XPS13 models were _also_ adversely affected (as were some other machines) by the ACPI changes that are about to be reverted. -Kamal [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight, revert) 2013-07-25 13:00 ` Rafael J. Wysocki @ 2013-07-25 14:52 ` Jörg Otte -1 siblings, 0 replies; 71+ messages in thread From: Jörg Otte @ 2013-07-25 14:52 UTC (permalink / raw) To: Rafael J. Wysocki Cc: James Hogan, Kamal Mostafa, Aaron Lu, Kalle Valo, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, Steven Newbury, ACPI Devel Maling List, Martin Steigerwald, Daniel Vetter, intel-gfx, Jani Nikula 2013/7/25 Rafael J. Wysocki <rjw@sisk.pl>: > On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote: >> On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote: >> > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: >> > > >> > > Linus, do you want me to send a pull request reverting 8c5bd7a and efaa14c? >> > >> > Yes, but let's wait a while. Not because I think we'll fix the problem >> > (hey, miracles might happen), but because I think it would be useful >> > to couple the reverts with information about the particular machines >> > that broke (and the people who reported it). So that when we >> > inevitably try again, we can perhaps get some testing effort with >> > those machines/people. >> > >> > It doesn't seem to be a show-stopped for a large number of people, so >> > there's no huge hurry. I'd suggest doing the revert just in time for >> > rc3, but waiting until then to gather info about people who see >> > breakage. >> > >> > Sound like a plan? >> >> Yes, it does. > > OK, time to revert I guess. > > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended patch > fixes the backlight for you. > Problems, problems :-) I tried to apply on top of 3.11-rc2: jojo@ahorn:/data/kernel/linux$ git log --pretty=oneline | head -5 3b2f64d00c46e1e4e9bd0bb9bb12619adac27a4b Linux 3.11-rc2 ea45ea70b6131fa0b006f5b687b9b1398b24f681 Merge tag 'acpi-video-3.11' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm 90db76e829479ef2ba1fed8f2552846015469831 Merge tag 'ext4_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 dda5690defe4af62ee120f055e98e40d97e4c760 ext3: fix a BUG when opening a file with O_TMPFILE flag e94bd3490f4ef342801cfc76b33d8baf9ccc9437 ext4: fix a BUG when opening a file with O_TMPFILE flag jojo@ahorn:/data/kernel/linux$ git apply --check /data/kernel/acpi-backlight-revert.patch error: patch failed: drivers/acpi/video.c:897 error: drivers/acpi/video.c: patch does not apply error: patch failed: drivers/gpu/drm/i915/i915_dma.c:1648 error: drivers/gpu/drm/i915/i915_dma.c: patch does not apply error: patch failed: include/acpi/video.h:17 error: include/acpi/video.h: patch does not apply error: patch failed: drivers/acpi/video_detect.c:235 error: drivers/acpi/video_detect.c: patch does not apply error: patch failed: include/linux/acpi.h:191 error: include/linux/acpi.h: patch does not apply error: patch failed: drivers/acpi/internal.h:169 error: drivers/acpi/internal.h: patch does not apply -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight, revert) @ 2013-07-25 14:52 ` Jörg Otte 0 siblings, 0 replies; 71+ messages in thread From: Jörg Otte @ 2013-07-25 14:52 UTC (permalink / raw) To: Rafael J. Wysocki Cc: James Hogan, Kamal Mostafa, Aaron Lu, Kalle Valo, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, Steven Newbury, ACPI Devel Maling List, Martin Steigerwald, Daniel Vetter, intel-gfx, Jani Nikula 2013/7/25 Rafael J. Wysocki <rjw@sisk.pl>: > On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote: >> On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote: >> > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: >> > > >> > > Linus, do you want me to send a pull request reverting 8c5bd7a and efaa14c? >> > >> > Yes, but let's wait a while. Not because I think we'll fix the problem >> > (hey, miracles might happen), but because I think it would be useful >> > to couple the reverts with information about the particular machines >> > that broke (and the people who reported it). So that when we >> > inevitably try again, we can perhaps get some testing effort with >> > those machines/people. >> > >> > It doesn't seem to be a show-stopped for a large number of people, so >> > there's no huge hurry. I'd suggest doing the revert just in time for >> > rc3, but waiting until then to gather info about people who see >> > breakage. >> > >> > Sound like a plan? >> >> Yes, it does. > > OK, time to revert I guess. > > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended patch > fixes the backlight for you. > Problems, problems :-) I tried to apply on top of 3.11-rc2: jojo@ahorn:/data/kernel/linux$ git log --pretty=oneline | head -5 3b2f64d00c46e1e4e9bd0bb9bb12619adac27a4b Linux 3.11-rc2 ea45ea70b6131fa0b006f5b687b9b1398b24f681 Merge tag 'acpi-video-3.11' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm 90db76e829479ef2ba1fed8f2552846015469831 Merge tag 'ext4_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 dda5690defe4af62ee120f055e98e40d97e4c760 ext3: fix a BUG when opening a file with O_TMPFILE flag e94bd3490f4ef342801cfc76b33d8baf9ccc9437 ext4: fix a BUG when opening a file with O_TMPFILE flag jojo@ahorn:/data/kernel/linux$ git apply --check /data/kernel/acpi-backlight-revert.patch error: patch failed: drivers/acpi/video.c:897 error: drivers/acpi/video.c: patch does not apply error: patch failed: drivers/gpu/drm/i915/i915_dma.c:1648 error: drivers/gpu/drm/i915/i915_dma.c: patch does not apply error: patch failed: include/acpi/video.h:17 error: include/acpi/video.h: patch does not apply error: patch failed: drivers/acpi/video_detect.c:235 error: drivers/acpi/video_detect.c: patch does not apply error: patch failed: include/linux/acpi.h:191 error: include/linux/acpi.h: patch does not apply error: patch failed: drivers/acpi/internal.h:169 error: drivers/acpi/internal.h: patch does not apply ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight, revert) 2013-07-25 14:52 ` Jörg Otte @ 2013-07-25 15:52 ` Jörg Otte -1 siblings, 0 replies; 71+ messages in thread From: Jörg Otte @ 2013-07-25 15:52 UTC (permalink / raw) To: Rafael J. Wysocki Cc: James Hogan, Kamal Mostafa, Aaron Lu, Kalle Valo, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, Steven Newbury, ACPI Devel Maling List, Martin Steigerwald, Daniel Vetter, intel-gfx, Jani Nikula 2013/7/25 Jörg Otte <jrg.otte@gmail.com>: > 2013/7/25 Rafael J. Wysocki <rjw@sisk.pl>: >> On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote: >>> On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote: >>> > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: >>> > > >>> > > Linus, do you want me to send a pull request reverting 8c5bd7a and efaa14c? >>> > >>> > Yes, but let's wait a while. Not because I think we'll fix the problem >>> > (hey, miracles might happen), but because I think it would be useful >>> > to couple the reverts with information about the particular machines >>> > that broke (and the people who reported it). So that when we >>> > inevitably try again, we can perhaps get some testing effort with >>> > those machines/people. >>> > >>> > It doesn't seem to be a show-stopped for a large number of people, so >>> > there's no huge hurry. I'd suggest doing the revert just in time for >>> > rc3, but waiting until then to gather info about people who see >>> > breakage. >>> > >>> > Sound like a plan? >>> >>> Yes, it does. >> >> OK, time to revert I guess. >> >> James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended patch >> fixes the backlight for you. >> > > Problems, problems :-) I tried to apply on top of 3.11-rc2: > Ok, with the help of Kamal I got my source tree back to a consistent state. The patch now applies successfully. Rafael, I now can confirm the patch fixes the problems for me. Thanks, Jörg -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight, revert) @ 2013-07-25 15:52 ` Jörg Otte 0 siblings, 0 replies; 71+ messages in thread From: Jörg Otte @ 2013-07-25 15:52 UTC (permalink / raw) To: Rafael J. Wysocki Cc: James Hogan, Kamal Mostafa, Aaron Lu, Kalle Valo, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, Steven Newbury, ACPI Devel Maling List, Martin Steigerwald, Daniel Vetter, intel-gfx, Jani Nikula 2013/7/25 Jörg Otte <jrg.otte@gmail.com>: > 2013/7/25 Rafael J. Wysocki <rjw@sisk.pl>: >> On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote: >>> On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote: >>> > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: >>> > > >>> > > Linus, do you want me to send a pull request reverting 8c5bd7a and efaa14c? >>> > >>> > Yes, but let's wait a while. Not because I think we'll fix the problem >>> > (hey, miracles might happen), but because I think it would be useful >>> > to couple the reverts with information about the particular machines >>> > that broke (and the people who reported it). So that when we >>> > inevitably try again, we can perhaps get some testing effort with >>> > those machines/people. >>> > >>> > It doesn't seem to be a show-stopped for a large number of people, so >>> > there's no huge hurry. I'd suggest doing the revert just in time for >>> > rc3, but waiting until then to gather info about people who see >>> > breakage. >>> > >>> > Sound like a plan? >>> >>> Yes, it does. >> >> OK, time to revert I guess. >> >> James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended patch >> fixes the backlight for you. >> > > Problems, problems :-) I tried to apply on top of 3.11-rc2: > Ok, with the help of Kamal I got my source tree back to a consistent state. The patch now applies successfully. Rafael, I now can confirm the patch fixes the problems for me. Thanks, Jörg ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight, revert) 2013-07-25 13:00 ` Rafael J. Wysocki @ 2013-07-25 19:14 ` James Hogan -1 siblings, 0 replies; 71+ messages in thread From: James Hogan @ 2013-07-25 19:14 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Kamal Mostafa, Aaron Lu, Kalle Valo, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, Steven Newbury, ACPI Devel Maling List, Jörg Otte, Martin Steigerwald, Daniel Vetter, intel-gfx, Jani Nikula On 25 July 2013 14:00, Rafael J. Wysocki <rjw@sisk.pl> wrote: > On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote: >> On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote: >> > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: >> > > >> > > Linus, do you want me to send a pull request reverting 8c5bd7a and efaa14c? >> > >> > Yes, but let's wait a while. Not because I think we'll fix the problem >> > (hey, miracles might happen), but because I think it would be useful >> > to couple the reverts with information about the particular machines >> > that broke (and the people who reported it). So that when we >> > inevitably try again, we can perhaps get some testing effort with >> > those machines/people. >> > >> > It doesn't seem to be a show-stopped for a large number of people, so >> > there's no huge hurry. I'd suggest doing the revert just in time for >> > rc3, but waiting until then to gather info about people who see >> > breakage. >> > >> > Sound like a plan? >> >> Yes, it does. > > OK, time to revert I guess. > > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended patch > fixes the backlight for you. Works for me Cheers James -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight, revert) @ 2013-07-25 19:14 ` James Hogan 0 siblings, 0 replies; 71+ messages in thread From: James Hogan @ 2013-07-25 19:14 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Kamal Mostafa, Aaron Lu, Kalle Valo, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, Steven Newbury, ACPI Devel Maling List, Jörg Otte, Martin Steigerwald, Daniel Vetter, intel-gfx, Jani Nikula On 25 July 2013 14:00, Rafael J. Wysocki <rjw@sisk.pl> wrote: > On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote: >> On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote: >> > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: >> > > >> > > Linus, do you want me to send a pull request reverting 8c5bd7a and efaa14c? >> > >> > Yes, but let's wait a while. Not because I think we'll fix the problem >> > (hey, miracles might happen), but because I think it would be useful >> > to couple the reverts with information about the particular machines >> > that broke (and the people who reported it). So that when we >> > inevitably try again, we can perhaps get some testing effort with >> > those machines/people. >> > >> > It doesn't seem to be a show-stopped for a large number of people, so >> > there's no huge hurry. I'd suggest doing the revert just in time for >> > rc3, but waiting until then to gather info about people who see >> > breakage. >> > >> > Sound like a plan? >> >> Yes, it does. > > OK, time to revert I guess. > > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended patch > fixes the backlight for you. Works for me Cheers James ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight, revert) 2013-07-25 19:14 ` James Hogan @ 2013-07-25 19:47 ` Rafael J. Wysocki -1 siblings, 0 replies; 71+ messages in thread From: Rafael J. Wysocki @ 2013-07-25 19:47 UTC (permalink / raw) To: James Hogan, Kamal Mostafa, Jörg Otte Cc: Aaron Lu, Kalle Valo, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, Steven Newbury, ACPI Devel Maling List, Martin Steigerwald, Daniel Vetter, intel-gfx, Jani Nikula On Thursday, July 25, 2013 08:14:08 PM James Hogan wrote: > On 25 July 2013 14:00, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote: > >> On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote: > >> > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > >> > > > >> > > Linus, do you want me to send a pull request reverting 8c5bd7a and efaa14c? > >> > > >> > Yes, but let's wait a while. Not because I think we'll fix the problem > >> > (hey, miracles might happen), but because I think it would be useful > >> > to couple the reverts with information about the particular machines > >> > that broke (and the people who reported it). So that when we > >> > inevitably try again, we can perhaps get some testing effort with > >> > those machines/people. > >> > > >> > It doesn't seem to be a show-stopped for a large number of people, so > >> > there's no huge hurry. I'd suggest doing the revert just in time for > >> > rc3, but waiting until then to gather info about people who see > >> > breakage. > >> > > >> > Sound like a plan? > >> > >> Yes, it does. > > > > OK, time to revert I guess. > > > > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended patch > > fixes the backlight for you. > > Works for me Great! James, Kamal, Jörg, thanks for confirmations. I'll tentatively put the revert into linux-next in a while. Other people who experienced problems with backlight in 3.11-rc2, please let me know whether or not the revert works for you too if you can. Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight, revert) @ 2013-07-25 19:47 ` Rafael J. Wysocki 0 siblings, 0 replies; 71+ messages in thread From: Rafael J. Wysocki @ 2013-07-25 19:47 UTC (permalink / raw) To: James Hogan, Kamal Mostafa, Jörg Otte Cc: Aaron Lu, Kalle Valo, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, Steven Newbury, ACPI Devel Maling List, Martin Steigerwald, Daniel Vetter, intel-gfx, Jani Nikula On Thursday, July 25, 2013 08:14:08 PM James Hogan wrote: > On 25 July 2013 14:00, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote: > >> On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote: > >> > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > >> > > > >> > > Linus, do you want me to send a pull request reverting 8c5bd7a and efaa14c? > >> > > >> > Yes, but let's wait a while. Not because I think we'll fix the problem > >> > (hey, miracles might happen), but because I think it would be useful > >> > to couple the reverts with information about the particular machines > >> > that broke (and the people who reported it). So that when we > >> > inevitably try again, we can perhaps get some testing effort with > >> > those machines/people. > >> > > >> > It doesn't seem to be a show-stopped for a large number of people, so > >> > there's no huge hurry. I'd suggest doing the revert just in time for > >> > rc3, but waiting until then to gather info about people who see > >> > breakage. > >> > > >> > Sound like a plan? > >> > >> Yes, it does. > > > > OK, time to revert I guess. > > > > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended patch > > fixes the backlight for you. > > Works for me Great! James, Kamal, Jörg, thanks for confirmations. I'll tentatively put the revert into linux-next in a while. Other people who experienced problems with backlight in 3.11-rc2, please let me know whether or not the revert works for you too if you can. Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight, revert) 2013-07-25 19:47 ` Rafael J. Wysocki (?) @ 2013-07-26 4:23 ` Joerg Platte -1 siblings, 0 replies; 71+ messages in thread From: Joerg Platte @ 2013-07-26 4:23 UTC (permalink / raw) To: Rafael J. Wysocki Cc: James Hogan, Kamal Mostafa, Jörg Otte, Aaron Lu, Kalle Valo, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, Steven Newbury, ACPI Devel Maling List, Martin Steigerwald, Daniel Vetter, intel-gfx, Jani Nikula On 25.07.2013 21:47, Rafael J. Wysocki wrote: > Other people who experienced problems with backlight in 3.11-rc2, please let me > know whether or not the revert works for you too if you can. Before reverting the patch /sys/class/backlight was empty and backlight brightness was set to max, now it again contains a link to acpi_video0 on my Thinkpad 420s with intel video and adjusting the backlight works again. Joerg ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight, revert) 2013-07-25 19:47 ` Rafael J. Wysocki @ 2013-07-26 11:22 ` Igor Gnatenko -1 siblings, 0 replies; 71+ messages in thread From: Igor Gnatenko @ 2013-07-26 11:22 UTC (permalink / raw) To: Rafael J. Wysocki Cc: James Hogan, Kamal Mostafa, Jörg Otte, Aaron Lu, Kalle Valo, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, Steven Newbury, ACPI Devel Maling List, Martin Steigerwald, Daniel Vetter, intel-gfx, Jani Nikula On Thu, 2013-07-25 at 21:47 +0200, Rafael J. Wysocki wrote: > On Thursday, July 25, 2013 08:14:08 PM James Hogan wrote: > > On 25 July 2013 14:00, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > > On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote: > > >> On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote: > > >> > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > >> > > > > >> > > Linus, do you want me to send a pull request reverting 8c5bd7a and efaa14c? > > >> > > > >> > Yes, but let's wait a while. Not because I think we'll fix the problem > > >> > (hey, miracles might happen), but because I think it would be useful > > >> > to couple the reverts with information about the particular machines > > >> > that broke (and the people who reported it). So that when we > > >> > inevitably try again, we can perhaps get some testing effort with > > >> > those machines/people. > > >> > > > >> > It doesn't seem to be a show-stopped for a large number of people, so > > >> > there's no huge hurry. I'd suggest doing the revert just in time for > > >> > rc3, but waiting until then to gather info about people who see > > >> > breakage. > > >> > > > >> > Sound like a plan? > > >> > > >> Yes, it does. > > > > > > OK, time to revert I guess. > > > > > > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended patch > > > fixes the backlight for you. > > > > Works for me > > Great! > > James, Kamal, Jörg, thanks for confirmations. I'll tentatively put the revert > into linux-next in a while. > > Other people who experienced problems with backlight in 3.11-rc2, please let me > know whether or not the revert works for you too if you can. > > Rafael > > Rafael, feel free to CC me in messages with backlight ;) I want to test its) -- Igor Gnatenko Fedora release 19 (Schrödinger’s Cat) Linux 3.9.9-302.fc19.x86_64 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight, revert) @ 2013-07-26 11:22 ` Igor Gnatenko 0 siblings, 0 replies; 71+ messages in thread From: Igor Gnatenko @ 2013-07-26 11:22 UTC (permalink / raw) To: Rafael J. Wysocki Cc: James Hogan, Kamal Mostafa, Jörg Otte, Aaron Lu, Kalle Valo, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, Steven Newbury, ACPI Devel Maling List, Martin Steigerwald, Daniel Vetter, intel-gfx, Jani Nikula On Thu, 2013-07-25 at 21:47 +0200, Rafael J. Wysocki wrote: > On Thursday, July 25, 2013 08:14:08 PM James Hogan wrote: > > On 25 July 2013 14:00, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > > On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote: > > >> On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote: > > >> > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > >> > > > > >> > > Linus, do you want me to send a pull request reverting 8c5bd7a and efaa14c? > > >> > > > >> > Yes, but let's wait a while. Not because I think we'll fix the problem > > >> > (hey, miracles might happen), but because I think it would be useful > > >> > to couple the reverts with information about the particular machines > > >> > that broke (and the people who reported it). So that when we > > >> > inevitably try again, we can perhaps get some testing effort with > > >> > those machines/people. > > >> > > > >> > It doesn't seem to be a show-stopped for a large number of people, so > > >> > there's no huge hurry. I'd suggest doing the revert just in time for > > >> > rc3, but waiting until then to gather info about people who see > > >> > breakage. > > >> > > > >> > Sound like a plan? > > >> > > >> Yes, it does. > > > > > > OK, time to revert I guess. > > > > > > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended patch > > > fixes the backlight for you. > > > > Works for me > > Great! > > James, Kamal, Jörg, thanks for confirmations. I'll tentatively put the revert > into linux-next in a while. > > Other people who experienced problems with backlight in 3.11-rc2, please let me > know whether or not the revert works for you too if you can. > > Rafael > > Rafael, feel free to CC me in messages with backlight ;) I want to test its) -- Igor Gnatenko Fedora release 19 (Schrödinger’s Cat) Linux 3.9.9-302.fc19.x86_64 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight, revert) 2013-07-25 13:00 ` Rafael J. Wysocki @ 2013-07-26 7:43 ` Steven Newbury -1 siblings, 0 replies; 71+ messages in thread From: Steven Newbury @ 2013-07-26 7:43 UTC (permalink / raw) To: Rafael J. Wysocki Cc: James Hogan, Kamal Mostafa, Aaron Lu, Kalle Valo, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, ACPI Devel Maling List, Jörg Otte, Martin Steigerwald, Daniel Vetter, intel-gfx, Jani Nikula On Thu, 2013-07-25 at 15:00 +0200, Rafael J. Wysocki wrote: > On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote: > > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote: > > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > > > > > > > Linus, do you want me to send a pull request reverting 8c5bd7a and efaa14c? > > > > > > Yes, but let's wait a while. Not because I think we'll fix the problem > > > (hey, miracles might happen), but because I think it would be useful > > > to couple the reverts with information about the particular machines > > > that broke (and the people who reported it). So that when we > > > inevitably try again, we can perhaps get some testing effort with > > > those machines/people. > > > > > > It doesn't seem to be a show-stopped for a large number of people, so > > > there's no huge hurry. I'd suggest doing the revert just in time for > > > rc3, but waiting until then to gather info about people who see > > > breakage. > > > > > > Sound like a plan? > > > > Yes, it does. > > OK, time to revert I guess. > > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended patch > fixes the backlight for you. > > Aaron, please double check if acpi_video_backlight_quirks() will still work as > needed. > > Thanks, > Rafael > > > --- > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > Subject: Revert "ACPI / video / i915: No ACPI backlight if firmware expects Windows 8" > > We attempted to address a regression introduced by commit a57f7f9 > (ACPICA: Add Windows8/Server2012 string for _OSI method.) after which > ACPI video backlight support doesn't work on a number of systems, > because the relevant AML methods in the ACPI tables in their BIOSes > become useless after the BIOS has been told that the OS is compatible > with Windows 8. That problem is tracked by the bug entry at: > > https://bugzilla.kernel.org/show_bug.cgi?id=51231 > > Commit 8c5bd7a (ACPI / video / i915: No ACPI backlight if firmware > expects Windows 8) introduced for this purpose essentially prevented > the ACPI backlight support from being used if the BIOS had been told > that the OS was compatible with Windows 8 and the i915 driver was > loaded, in which case the backlight would always be handled by i915. > Unfortunately, however, that turned out to cause problems with > backlight to appear on multiple systems with symptoms indicating that > i915 was unable to control the backlight on those systems as > expected. > > For this reason, revert commit 8c5bd7a, but leave the function > acpi_video_backlight_quirks() introduced by it, because another > commit on top of it uses that function. > Works fine for me. Tested-by: Steven Newbury <steve@snewbury.org.uk> By the way, I'm willing to test any i915 backlight patches if it helps. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight, revert) @ 2013-07-26 7:43 ` Steven Newbury 0 siblings, 0 replies; 71+ messages in thread From: Steven Newbury @ 2013-07-26 7:43 UTC (permalink / raw) To: Rafael J. Wysocki Cc: James Hogan, Kamal Mostafa, Aaron Lu, Kalle Valo, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, ACPI Devel Maling List, Jörg Otte, Martin Steigerwald, Daniel Vetter, intel-gfx, Jani Nikula On Thu, 2013-07-25 at 15:00 +0200, Rafael J. Wysocki wrote: > On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote: > > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote: > > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > > > > > > > Linus, do you want me to send a pull request reverting 8c5bd7a and efaa14c? > > > > > > Yes, but let's wait a while. Not because I think we'll fix the problem > > > (hey, miracles might happen), but because I think it would be useful > > > to couple the reverts with information about the particular machines > > > that broke (and the people who reported it). So that when we > > > inevitably try again, we can perhaps get some testing effort with > > > those machines/people. > > > > > > It doesn't seem to be a show-stopped for a large number of people, so > > > there's no huge hurry. I'd suggest doing the revert just in time for > > > rc3, but waiting until then to gather info about people who see > > > breakage. > > > > > > Sound like a plan? > > > > Yes, it does. > > OK, time to revert I guess. > > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended patch > fixes the backlight for you. > > Aaron, please double check if acpi_video_backlight_quirks() will still work as > needed. > > Thanks, > Rafael > > > --- > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > Subject: Revert "ACPI / video / i915: No ACPI backlight if firmware expects Windows 8" > > We attempted to address a regression introduced by commit a57f7f9 > (ACPICA: Add Windows8/Server2012 string for _OSI method.) after which > ACPI video backlight support doesn't work on a number of systems, > because the relevant AML methods in the ACPI tables in their BIOSes > become useless after the BIOS has been told that the OS is compatible > with Windows 8. That problem is tracked by the bug entry at: > > https://bugzilla.kernel.org/show_bug.cgi?id=51231 > > Commit 8c5bd7a (ACPI / video / i915: No ACPI backlight if firmware > expects Windows 8) introduced for this purpose essentially prevented > the ACPI backlight support from being used if the BIOS had been told > that the OS was compatible with Windows 8 and the i915 driver was > loaded, in which case the backlight would always be handled by i915. > Unfortunately, however, that turned out to cause problems with > backlight to appear on multiple systems with symptoms indicating that > i915 was unable to control the backlight on those systems as > expected. > > For this reason, revert commit 8c5bd7a, but leave the function > acpi_video_backlight_quirks() introduced by it, because another > commit on top of it uses that function. > Works fine for me. Tested-by: Steven Newbury <steve@snewbury.org.uk> By the way, I'm willing to test any i915 backlight patches if it helps. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight, revert) 2013-07-25 13:00 ` Rafael J. Wysocki @ 2013-07-26 12:09 ` Martin Steigerwald -1 siblings, 0 replies; 71+ messages in thread From: Martin Steigerwald @ 2013-07-26 12:09 UTC (permalink / raw) To: Rafael J. Wysocki Cc: James Hogan, Kamal Mostafa, Aaron Lu, Kalle Valo, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, Steven Newbury, ACPI Devel Maling List, Jörg Otte, Daniel Vetter, intel-gfx, Jani Nikula Am Donnerstag, 25. Juli 2013, 15:00:26 schrieb Rafael J. Wysocki: > On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote: > > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote: > > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > > > Linus, do you want me to send a pull request reverting 8c5bd7a and > > > > efaa14c? > > > > > > Yes, but let's wait a while. Not because I think we'll fix the problem > > > (hey, miracles might happen), but because I think it would be useful > > > to couple the reverts with information about the particular machines > > > that broke (and the people who reported it). So that when we > > > inevitably try again, we can perhaps get some testing effort with > > > those machines/people. > > > > > > It doesn't seem to be a show-stopped for a large number of people, so > > > there's no huge hurry. I'd suggest doing the revert just in time for > > > rc3, but waiting until then to gather info about people who see > > > breakage. > > > > > > Sound like a plan? > > > > Yes, it does. > > OK, time to revert I guess. > > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended > patch fixes the backlight for you. Rafael, do you still need more testing urgently? Otherwise I´d wait till its in some next 3.11 rc and test then. Thanks, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight, revert) @ 2013-07-26 12:09 ` Martin Steigerwald 0 siblings, 0 replies; 71+ messages in thread From: Martin Steigerwald @ 2013-07-26 12:09 UTC (permalink / raw) To: Rafael J. Wysocki Cc: James Hogan, Kamal Mostafa, Aaron Lu, Kalle Valo, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, Steven Newbury, ACPI Devel Maling List, Jörg Otte, Daniel Vetter, intel-gfx, Jani Nikula Am Donnerstag, 25. Juli 2013, 15:00:26 schrieb Rafael J. Wysocki: > On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote: > > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote: > > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > > > Linus, do you want me to send a pull request reverting 8c5bd7a and > > > > efaa14c? > > > > > > Yes, but let's wait a while. Not because I think we'll fix the problem > > > (hey, miracles might happen), but because I think it would be useful > > > to couple the reverts with information about the particular machines > > > that broke (and the people who reported it). So that when we > > > inevitably try again, we can perhaps get some testing effort with > > > those machines/people. > > > > > > It doesn't seem to be a show-stopped for a large number of people, so > > > there's no huge hurry. I'd suggest doing the revert just in time for > > > rc3, but waiting until then to gather info about people who see > > > breakage. > > > > > > Sound like a plan? > > > > Yes, it does. > > OK, time to revert I guess. > > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended > patch fixes the backlight for you. Rafael, do you still need more testing urgently? Otherwise I´d wait till its in some next 3.11 rc and test then. Thanks, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight, revert) 2013-07-26 12:09 ` Martin Steigerwald @ 2013-07-26 12:40 ` Rafael J. Wysocki -1 siblings, 0 replies; 71+ messages in thread From: Rafael J. Wysocki @ 2013-07-26 12:40 UTC (permalink / raw) To: Martin Steigerwald, Steven Newbury, Joerg Platte Cc: James Hogan, Kamal Mostafa, Aaron Lu, Kalle Valo, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, ACPI Devel Maling List, Jörg Otte, Daniel Vetter, intel-gfx, Jani Nikula On Friday, July 26, 2013 02:09:08 PM Martin Steigerwald wrote: > Am Donnerstag, 25. Juli 2013, 15:00:26 schrieb Rafael J. Wysocki: > > On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote: > > > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote: > > > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > > > > Linus, do you want me to send a pull request reverting 8c5bd7a and > > > > > efaa14c? > > > > > > > > Yes, but let's wait a while. Not because I think we'll fix the problem > > > > (hey, miracles might happen), but because I think it would be useful > > > > to couple the reverts with information about the particular machines > > > > that broke (and the people who reported it). So that when we > > > > inevitably try again, we can perhaps get some testing effort with > > > > those machines/people. > > > > > > > > It doesn't seem to be a show-stopped for a large number of people, so > > > > there's no huge hurry. I'd suggest doing the revert just in time for > > > > rc3, but waiting until then to gather info about people who see > > > > breakage. > > > > > > > > Sound like a plan? > > > > > > Yes, it does. > > > > OK, time to revert I guess. > > > > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended > > patch fixes the backlight for you. > > Rafael, do you still need more testing urgently? Otherwise I´d wait till its > in some next 3.11 rc and test then. Well, it seems to work for everybody else (Steven, Joerg, thanks for your reports!), so I don't think you need to test it urgently. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight, revert) @ 2013-07-26 12:40 ` Rafael J. Wysocki 0 siblings, 0 replies; 71+ messages in thread From: Rafael J. Wysocki @ 2013-07-26 12:40 UTC (permalink / raw) To: Martin Steigerwald, Steven Newbury, Joerg Platte Cc: James Hogan, Kamal Mostafa, Aaron Lu, Kalle Valo, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, ACPI Devel Maling List, Jörg Otte, Daniel Vetter, intel-gfx, Jani Nikula On Friday, July 26, 2013 02:09:08 PM Martin Steigerwald wrote: > Am Donnerstag, 25. Juli 2013, 15:00:26 schrieb Rafael J. Wysocki: > > On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote: > > > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote: > > > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > > > > Linus, do you want me to send a pull request reverting 8c5bd7a and > > > > > efaa14c? > > > > > > > > Yes, but let's wait a while. Not because I think we'll fix the problem > > > > (hey, miracles might happen), but because I think it would be useful > > > > to couple the reverts with information about the particular machines > > > > that broke (and the people who reported it). So that when we > > > > inevitably try again, we can perhaps get some testing effort with > > > > those machines/people. > > > > > > > > It doesn't seem to be a show-stopped for a large number of people, so > > > > there's no huge hurry. I'd suggest doing the revert just in time for > > > > rc3, but waiting until then to gather info about people who see > > > > breakage. > > > > > > > > Sound like a plan? > > > > > > Yes, it does. > > > > OK, time to revert I guess. > > > > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended > > patch fixes the backlight for you. > > Rafael, do you still need more testing urgently? Otherwise I´d wait till its > in some next 3.11 rc and test then. Well, it seems to work for everybody else (Steven, Joerg, thanks for your reports!), so I don't think you need to test it urgently. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight, revert) 2013-07-26 12:40 ` Rafael J. Wysocki @ 2013-08-04 19:33 ` Martin Steigerwald -1 siblings, 0 replies; 71+ messages in thread From: Martin Steigerwald @ 2013-08-04 19:33 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Steven Newbury, Joerg Platte, James Hogan, Kamal Mostafa, Aaron Lu, Kalle Valo, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, ACPI Devel Maling List, Jörg Otte, Daniel Vetter, intel-gfx, Jani Nikula Am Freitag, 26. Juli 2013, 14:40:58 schrieb Rafael J. Wysocki: > On Friday, July 26, 2013 02:09:08 PM Martin Steigerwald wrote: > > Am Donnerstag, 25. Juli 2013, 15:00:26 schrieb Rafael J. Wysocki: > > > On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote: > > > > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote: > > > > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > > > > > Linus, do you want me to send a pull request reverting 8c5bd7a and > > > > > > efaa14c? > > > > > > > > > > Yes, but let's wait a while. Not because I think we'll fix the > > > > > problem > > > > > (hey, miracles might happen), but because I think it would be useful > > > > > to couple the reverts with information about the particular machines > > > > > that broke (and the people who reported it). So that when we > > > > > inevitably try again, we can perhaps get some testing effort with > > > > > those machines/people. > > > > > > > > > > It doesn't seem to be a show-stopped for a large number of people, > > > > > so > > > > > there's no huge hurry. I'd suggest doing the revert just in time for > > > > > rc3, but waiting until then to gather info about people who see > > > > > breakage. > > > > > > > > > > Sound like a plan? > > > > > > > > Yes, it does. > > > > > > OK, time to revert I guess. > > > > > > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended > > > patch fixes the backlight for you. > > > > Rafael, do you still need more testing urgently? Otherwise I´d wait till > > its in some next 3.11 rc and test then. > > Well, it seems to work for everybody else (Steven, Joerg, thanks for your > reports!), so I don't think you need to test it urgently. Just a late confirmation: With 3.11-rc3 back light stuff is working nicely on this ThinkPad T520. Thanks, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight, revert) @ 2013-08-04 19:33 ` Martin Steigerwald 0 siblings, 0 replies; 71+ messages in thread From: Martin Steigerwald @ 2013-08-04 19:33 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Steven Newbury, Joerg Platte, James Hogan, Kamal Mostafa, Aaron Lu, Kalle Valo, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, ACPI Devel Maling List, Jörg Otte, Daniel Vetter, intel-gfx, Jani Nikula Am Freitag, 26. Juli 2013, 14:40:58 schrieb Rafael J. Wysocki: > On Friday, July 26, 2013 02:09:08 PM Martin Steigerwald wrote: > > Am Donnerstag, 25. Juli 2013, 15:00:26 schrieb Rafael J. Wysocki: > > > On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote: > > > > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote: > > > > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > > > > > Linus, do you want me to send a pull request reverting 8c5bd7a and > > > > > > efaa14c? > > > > > > > > > > Yes, but let's wait a while. Not because I think we'll fix the > > > > > problem > > > > > (hey, miracles might happen), but because I think it would be useful > > > > > to couple the reverts with information about the particular machines > > > > > that broke (and the people who reported it). So that when we > > > > > inevitably try again, we can perhaps get some testing effort with > > > > > those machines/people. > > > > > > > > > > It doesn't seem to be a show-stopped for a large number of people, > > > > > so > > > > > there's no huge hurry. I'd suggest doing the revert just in time for > > > > > rc3, but waiting until then to gather info about people who see > > > > > breakage. > > > > > > > > > > Sound like a plan? > > > > > > > > Yes, it does. > > > > > > OK, time to revert I guess. > > > > > > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended > > > patch fixes the backlight for you. > > > > Rafael, do you still need more testing urgently? Otherwise I´d wait till > > its in some next 3.11 rc and test then. > > Well, it seems to work for everybody else (Steven, Joerg, thanks for your > reports!), so I don't think you need to test it urgently. Just a late confirmation: With 3.11-rc3 back light stuff is working nicely on this ThinkPad T520. Thanks, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight, revert) 2013-08-04 19:33 ` Martin Steigerwald @ 2013-08-04 22:15 ` Rafael J. Wysocki -1 siblings, 0 replies; 71+ messages in thread From: Rafael J. Wysocki @ 2013-08-04 22:15 UTC (permalink / raw) To: Martin Steigerwald Cc: Aaron Lu, James Hogan, Joerg Platte, Rafael J. Wysocki, Linux Kernel Mailing List, ACPI Devel Maling List, Jörg Otte, Daniel Vetter, intel-gfx, Matthew Garrett, Linus Torvalds, Kalle Valo On Sunday, August 04, 2013 09:33:43 PM Martin Steigerwald wrote: > Am Freitag, 26. Juli 2013, 14:40:58 schrieb Rafael J. Wysocki: > > On Friday, July 26, 2013 02:09:08 PM Martin Steigerwald wrote: > > > Am Donnerstag, 25. Juli 2013, 15:00:26 schrieb Rafael J. Wysocki: > > > > On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote: > > > > > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote: > > > > > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <rjw@sisk.pl> > wrote: > > > > > > > Linus, do you want me to send a pull request reverting 8c5bd7a and > > > > > > > efaa14c? > > > > > > > > > > > > Yes, but let's wait a while. Not because I think we'll fix the > > > > > > problem > > > > > > (hey, miracles might happen), but because I think it would be useful > > > > > > to couple the reverts with information about the particular machines > > > > > > that broke (and the people who reported it). So that when we > > > > > > inevitably try again, we can perhaps get some testing effort with > > > > > > those machines/people. > > > > > > > > > > > > It doesn't seem to be a show-stopped for a large number of people, > > > > > > so > > > > > > there's no huge hurry. I'd suggest doing the revert just in time for > > > > > > rc3, but waiting until then to gather info about people who see > > > > > > breakage. > > > > > > > > > > > > Sound like a plan? > > > > > > > > > > Yes, it does. > > > > > > > > OK, time to revert I guess. > > > > > > > > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended > > > > patch fixes the backlight for you. > > > > > > Rafael, do you still need more testing urgently? Otherwise I´d wait till > > > its in some next 3.11 rc and test then. > > > > Well, it seems to work for everybody else (Steven, Joerg, thanks for your > > reports!), so I don't think you need to test it urgently. > > Just a late confirmation: With 3.11-rc3 back light stuff is working nicely on > this ThinkPad T520. Thanks! _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight, revert) @ 2013-08-04 22:15 ` Rafael J. Wysocki 0 siblings, 0 replies; 71+ messages in thread From: Rafael J. Wysocki @ 2013-08-04 22:15 UTC (permalink / raw) To: Martin Steigerwald Cc: Steven Newbury, Joerg Platte, James Hogan, Kamal Mostafa, Aaron Lu, Kalle Valo, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, ACPI Devel Maling List, Jörg Otte, Daniel Vetter, intel-gfx, Jani Nikula On Sunday, August 04, 2013 09:33:43 PM Martin Steigerwald wrote: > Am Freitag, 26. Juli 2013, 14:40:58 schrieb Rafael J. Wysocki: > > On Friday, July 26, 2013 02:09:08 PM Martin Steigerwald wrote: > > > Am Donnerstag, 25. Juli 2013, 15:00:26 schrieb Rafael J. Wysocki: > > > > On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote: > > > > > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote: > > > > > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <rjw@sisk.pl> > wrote: > > > > > > > Linus, do you want me to send a pull request reverting 8c5bd7a and > > > > > > > efaa14c? > > > > > > > > > > > > Yes, but let's wait a while. Not because I think we'll fix the > > > > > > problem > > > > > > (hey, miracles might happen), but because I think it would be useful > > > > > > to couple the reverts with information about the particular machines > > > > > > that broke (and the people who reported it). So that when we > > > > > > inevitably try again, we can perhaps get some testing effort with > > > > > > those machines/people. > > > > > > > > > > > > It doesn't seem to be a show-stopped for a large number of people, > > > > > > so > > > > > > there's no huge hurry. I'd suggest doing the revert just in time for > > > > > > rc3, but waiting until then to gather info about people who see > > > > > > breakage. > > > > > > > > > > > > Sound like a plan? > > > > > > > > > > Yes, it does. > > > > > > > > OK, time to revert I guess. > > > > > > > > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended > > > > patch fixes the backlight for you. > > > > > > Rafael, do you still need more testing urgently? Otherwise I´d wait till > > > its in some next 3.11 rc and test then. > > > > Well, it seems to work for everybody else (Steven, Joerg, thanks for your > > reports!), so I don't think you need to test it urgently. > > Just a late confirmation: With 3.11-rc3 back light stuff is working nicely on > this ThinkPad T520. Thanks! ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight, revert) 2013-07-25 13:00 ` Rafael J. Wysocki ` (6 preceding siblings ...) (?) @ 2013-07-27 5:34 ` Kalle Valo 2013-07-27 12:18 ` Rafael J. Wysocki -1 siblings, 1 reply; 71+ messages in thread From: Kalle Valo @ 2013-07-27 5:34 UTC (permalink / raw) To: Rafael J. Wysocki Cc: James Hogan, Kamal Mostafa, Aaron Lu, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, Steven Newbury, ACPI Devel Maling List, Jörg Otte, Martin Steigerwald, Daniel Vetter, intel-gfx, Jani Nikula "Rafael J. Wysocki" <rjw@sisk.pl> writes: > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended patch > fixes the backlight for you. I did three suspend-resume cycles and didn't notice anything wrong so this patch fixes the issue for me. I'll continue testing and will report if I spot any problems. Tested-by: Kalle Valo <kvalo@adurom.com> -- Kalle Valo ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight, revert) 2013-07-27 5:34 ` Kalle Valo @ 2013-07-27 12:18 ` Rafael J. Wysocki 0 siblings, 0 replies; 71+ messages in thread From: Rafael J. Wysocki @ 2013-07-27 12:18 UTC (permalink / raw) To: Kalle Valo Cc: James Hogan, Kamal Mostafa, Aaron Lu, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, Steven Newbury, ACPI Devel Maling List, Jörg Otte, Martin Steigerwald, Daniel Vetter, intel-gfx, Jani Nikula On Saturday, July 27, 2013 08:34:13 AM Kalle Valo wrote: > "Rafael J. Wysocki" <rjw@sisk.pl> writes: > > > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended patch > > fixes the backlight for you. > > I did three suspend-resume cycles and didn't notice anything wrong so > this patch fixes the issue for me. I'll continue testing and will report > if I spot any problems. > > Tested-by: Kalle Valo <kvalo@adurom.com> Thanks a lot for the confirmation, this already is in the Linus' tree. Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 (acpi backlight, revert) @ 2013-07-27 12:18 ` Rafael J. Wysocki 0 siblings, 0 replies; 71+ messages in thread From: Rafael J. Wysocki @ 2013-07-27 12:18 UTC (permalink / raw) To: Kalle Valo Cc: James Hogan, Kamal Mostafa, Aaron Lu, Linus Torvalds, Linux Kernel Mailing List, Matthew Garrett, Rafael J. Wysocki, Steven Newbury, ACPI Devel Maling List, Jörg Otte, Martin Steigerwald, Daniel Vetter, intel-gfx, Jani Nikula On Saturday, July 27, 2013 08:34:13 AM Kalle Valo wrote: > "Rafael J. Wysocki" <rjw@sisk.pl> writes: > > > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended patch > > fixes the backlight for you. > > I did three suspend-resume cycles and didn't notice anything wrong so > this patch fixes the issue for me. I'll continue testing and will report > if I spot any problems. > > Tested-by: Kalle Valo <kvalo@adurom.com> Thanks a lot for the confirmation, this already is in the Linus' tree. Rafael ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 2013-07-22 13:02 ` Rafael J. Wysocki ` (2 preceding siblings ...) 2013-07-22 18:11 ` Linus Torvalds @ 2013-07-22 18:16 ` Matthew Garrett 2013-07-22 19:56 ` Rafael J. Wysocki 3 siblings, 1 reply; 71+ messages in thread From: Matthew Garrett @ 2013-07-22 18:16 UTC (permalink / raw) To: Rafael J. Wysocki Cc: James Hogan, Linus Torvalds, Linux Kernel Mailing List, Kamal Mostafa, Rafael J. Wysocki, Steven Newbury [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 526 bytes --] On Mon, 2013-07-22 at 15:02 +0200, Rafael J. Wysocki wrote: > In the meantime I received a report from Steven Newbury that these changes > broke things for him too, so we need to revert commits 8c5bd7a and efaa14c. > The other two commits in the series should be benign. Could you let me know the details of this problem? -- Matthew Garrett | mjg59@srcf.ucam.org ÿôèº{.nÇ+·®+%Ëÿ±éݶ\x17¥wÿº{.nÇ+·¥{±þG«éÿ{ayº\x1dÊÚë,j\a¢f£¢·hïêÿêçz_è®\x03(éÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?¨èÚ&£ø§~á¶iOæ¬z·vØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?I¥ ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 2013-07-22 18:16 ` Linux 3.11-rc2 Matthew Garrett @ 2013-07-22 19:56 ` Rafael J. Wysocki 2013-07-23 17:47 ` Steven Newbury 0 siblings, 1 reply; 71+ messages in thread From: Rafael J. Wysocki @ 2013-07-22 19:56 UTC (permalink / raw) To: Matthew Garrett, Steven Newbury Cc: James Hogan, Linus Torvalds, Linux Kernel Mailing List, Kamal Mostafa, Rafael J. Wysocki, ACPI Devel Maling List On Monday, July 22, 2013 06:16:20 PM Matthew Garrett wrote: > On Mon, 2013-07-22 at 15:02 +0200, Rafael J. Wysocki wrote: > > > In the meantime I received a report from Steven Newbury that these changes > > broke things for him too, so we need to revert commits 8c5bd7a and efaa14c. > > The other two commits in the series should be benign. > > Could you let me know the details of this problem? Steven, can you please describe the problem you're seeing to Matthew and the other people on the list? Rafael ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 2013-07-22 19:56 ` Rafael J. Wysocki @ 2013-07-23 17:47 ` Steven Newbury 2013-07-23 19:51 ` Matthew Garrett 2013-07-23 21:24 ` Rafael J. Wysocki 0 siblings, 2 replies; 71+ messages in thread From: Steven Newbury @ 2013-07-23 17:47 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Matthew Garrett, James Hogan, Linus Torvalds, Linux Kernel Mailing List, Kamal Mostafa, Rafael J. Wysocki, ACPI Devel Maling List On Mon, 2013-07-22 at 21:56 +0200, Rafael J. Wysocki wrote: > On Monday, July 22, 2013 06:16:20 PM Matthew Garrett wrote: > > On Mon, 2013-07-22 at 15:02 +0200, Rafael J. Wysocki wrote: > > > > > In the meantime I received a report from Steven Newbury that these changes > > > broke things for him too, so we need to revert commits 8c5bd7a and efaa14c. > > > The other two commits in the series should be benign. > > > > Could you let me know the details of this problem? > > Steven, can you please describe the problem you're seeing to Matthew and > the other people on the list? > > Rafael > Before the changes backlight was working fine using the ACPI method: /sys/class/backlight/acpi_video0/ is present and the keyboard function keys control brightness with notifications working in GNOME. In the code as was present in the linux-pm/bleeding-edge tree I would encounter a hard lockup on keyboard brightness trigger. This also occurred with the code as it initially hit mainline, but a later commit fixed the crash*, but resulted in no backlight controls being available at all. /sys/class/backlight is empty. *not actually sure if /sys/class/backlight contained anything before this ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 2013-07-23 17:47 ` Steven Newbury @ 2013-07-23 19:51 ` Matthew Garrett 2013-07-23 21:24 ` Rafael J. Wysocki 1 sibling, 0 replies; 71+ messages in thread From: Matthew Garrett @ 2013-07-23 19:51 UTC (permalink / raw) To: Steven Newbury Cc: Rafael J. Wysocki, James Hogan, Linus Torvalds, Linux Kernel Mailing List, Kamal Mostafa, Rafael J. Wysocki, ACPI Devel Maling List On Tue, 2013-07-23 at 18:47 +0100, Steven Newbury wrote: > In the code as was present in the linux-pm/bleeding-edge tree I would > encounter a hard lockup on keyboard brightness trigger. This also occurred with > the code as it initially hit mainline, but a later commit fixed the crash*, but > resulted in no backlight controls being available at all. > /sys/class/backlight is empty. This is an Intel system using the i915 driver? -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 @ 2013-07-23 19:51 ` Matthew Garrett 0 siblings, 0 replies; 71+ messages in thread From: Matthew Garrett @ 2013-07-23 19:51 UTC (permalink / raw) To: Steven Newbury Cc: Rafael J. Wysocki, James Hogan, Linus Torvalds, Linux Kernel Mailing List, Kamal Mostafa, Rafael J. Wysocki, ACPI Devel Maling List [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 640 bytes --] On Tue, 2013-07-23 at 18:47 +0100, Steven Newbury wrote: > In the code as was present in the linux-pm/bleeding-edge tree I would > encounter a hard lockup on keyboard brightness trigger. This also occurred with > the code as it initially hit mainline, but a later commit fixed the crash*, but > resulted in no backlight controls being available at all. > /sys/class/backlight is empty. This is an Intel system using the i915 driver? -- Matthew Garrett | mjg59@srcf.ucam.org ÿôèº{.nÇ+·®+%Ëÿ±éݶ\x17¥wÿº{.nÇ+·¥{±þG«éÿ{ayº\x1dÊÚë,j\a¢f£¢·hïêÿêçz_è®\x03(éÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?¨èÚ&£ø§~á¶iOæ¬z·vØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?I¥ ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 2013-07-23 19:51 ` Matthew Garrett (?) @ 2013-07-23 21:10 ` Steven Newbury -1 siblings, 0 replies; 71+ messages in thread From: Steven Newbury @ 2013-07-23 21:10 UTC (permalink / raw) To: Matthew Garrett Cc: Rafael J. Wysocki, James Hogan, Linus Torvalds, Linux Kernel Mailing List, Kamal Mostafa, Rafael J. Wysocki, ACPI Devel Maling List On Tue, 2013-07-23 at 19:51 +0000, Matthew Garrett wrote: > On Tue, 2013-07-23 at 18:47 +0100, Steven Newbury wrote: > > > In the code as was present in the linux-pm/bleeding-edge tree I would > > encounter a hard lockup on keyboard brightness trigger. This also occurred with > > the code as it initially hit mainline, but a later commit fixed the crash*, but > > resulted in no backlight controls being available at all. > > /sys/class/backlight is empty. > > This is an Intel system using the i915 driver? > Yes, IVB i7-3840QM. CLEVO W270EUQ. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 2013-07-23 17:47 ` Steven Newbury 2013-07-23 19:51 ` Matthew Garrett @ 2013-07-23 21:24 ` Rafael J. Wysocki 2013-07-23 22:49 ` Steven Newbury 1 sibling, 1 reply; 71+ messages in thread From: Rafael J. Wysocki @ 2013-07-23 21:24 UTC (permalink / raw) To: Steven Newbury Cc: Matthew Garrett, James Hogan, Linus Torvalds, Linux Kernel Mailing List, Kamal Mostafa, Rafael J. Wysocki, ACPI Devel Maling List On Tuesday, July 23, 2013 06:47:55 PM Steven Newbury wrote: > On Mon, 2013-07-22 at 21:56 +0200, Rafael J. Wysocki wrote: > > On Monday, July 22, 2013 06:16:20 PM Matthew Garrett wrote: > > > On Mon, 2013-07-22 at 15:02 +0200, Rafael J. Wysocki wrote: > > > > > > > In the meantime I received a report from Steven Newbury that these changes > > > > broke things for him too, so we need to revert commits 8c5bd7a and efaa14c. > > > > The other two commits in the series should be benign. > > > > > > Could you let me know the details of this problem? > > > > Steven, can you please describe the problem you're seeing to Matthew and > > the other people on the list? > > > > Rafael > > > > Before the changes backlight was working fine using the ACPI method: > /sys/class/backlight/acpi_video0/ is present and the keyboard function keys > control brightness with notifications working in GNOME. > > In the code as was present in the linux-pm/bleeding-edge tree I would > encounter a hard lockup on keyboard brightness trigger. This also occurred with > the code as it initially hit mainline, but a later commit fixed the crash*, but > resulted in no backlight controls being available at all. > /sys/class/backlight is empty. > > *not actually sure if /sys/class/backlight contained anything before this Hmm. Which commit fixed the crash for you? Rafael ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 2013-07-23 21:24 ` Rafael J. Wysocki @ 2013-07-23 22:49 ` Steven Newbury 0 siblings, 0 replies; 71+ messages in thread From: Steven Newbury @ 2013-07-23 22:49 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Matthew Garrett, James Hogan, Linus Torvalds, Linux Kernel Mailing List, Kamal Mostafa, Rafael J. Wysocki, ACPI Devel Maling List On Tue, 2013-07-23 at 23:24 +0200, Rafael J. Wysocki wrote: > On Tuesday, July 23, 2013 06:47:55 PM Steven Newbury wrote: > > On Mon, 2013-07-22 at 21:56 +0200, Rafael J. Wysocki wrote: > > > On Monday, July 22, 2013 06:16:20 PM Matthew Garrett wrote: > > > > On Mon, 2013-07-22 at 15:02 +0200, Rafael J. Wysocki wrote: > > > > > > > > > In the meantime I received a report from Steven Newbury that these changes > > > > > broke things for him too, so we need to revert commits 8c5bd7a and efaa14c. > > > > > The other two commits in the series should be benign. > > > > > > > > Could you let me know the details of this problem? > > > > > > Steven, can you please describe the problem you're seeing to Matthew and > > > the other people on the list? > > > > > > Rafael > > > > > > > Before the changes backlight was working fine using the ACPI method: > > /sys/class/backlight/acpi_video0/ is present and the keyboard function keys > > control brightness with notifications working in GNOME. > > > > In the code as was present in the linux-pm/bleeding-edge tree I would > > encounter a hard lockup on keyboard brightness trigger. This also occurred with > > the code as it initially hit mainline, but a later commit fixed the crash*, but > > resulted in no backlight controls being available at all. > > /sys/class/backlight is empty. > > > > *not actually sure if /sys/class/backlight contained anything before this > > Hmm. Which commit fixed the crash for you? > > Rafael > I'll see if I can build a broken kernel tomorrow, after backing up! ;-) ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 2013-07-21 19:53 Linux 3.11-rc2 Linus Torvalds 2013-07-21 21:07 ` Tobias Klausmann 2013-07-21 23:08 ` James Hogan @ 2013-07-22 1:25 ` Dave Chinner 2013-07-22 4:06 ` Al Viro 2013-07-23 1:04 ` rydberg 3 siblings, 1 reply; 71+ messages in thread From: Dave Chinner @ 2013-07-22 1:25 UTC (permalink / raw) To: Linus Torvalds; +Cc: Linux Kernel Mailing List On Sun, Jul 21, 2013 at 12:53:10PM -0700, Linus Torvalds wrote: > So it's been another week, and -rc2 is out there. > > The patch looks a bit odd, because by bulk 95% of the patch is just > the removal of the CSR staging driver that wasn't getting any > traction, so the diffstat (and the dirstat in particular) is not very > interesting or readable, since that driver removal basically > overshadows everything else. But I do admit to love seeing code > removal patches. > > And of the rest of the patch, a noticeable part is all those > one-liners all over that just remove the __cpuinit markers that people > agreed were just more pain than gain to maintain. We had already made > the markers be no-ops earlier, so they didn't matter for code > generation, and here in rc2 they get actually removed. > > End result: we have two separate events that generate a lot of noise > in the patch, but aren't really interesting per se. They do make the > patch harder to read, though. > > Ignoring those noisy parts of the patch, there's a couple of things > worth noting about rc2. I think most of the patches here are nice > fixes, but I wanted to give two heads-ups: > > (a) the O_TMPFILE flag that is new to 3.11 has been going through a > few ABI/API cleanups (and a few fixes to the implementation too), but > I think we're done now. So if you're interested in the concept of > unnamed temporary files, go ahead and test it out. The lack of name > not only gets rid of races/complications with filename generation, it > can make the whole thing more efficient since you don't have the > directory operations that can cause serializing IO etc. I'll just point out that it can make the whole thing worse, too. For example, for ext3/4, the tmpfile being created has to be added to the orphan inode list which is protected by a filesystem global mutex. Hence scalability of O_TMPFILE is massively limited on ext3/ext4 due to architectural issues within ext3/4. Other filesystems will be more efficient, but because they have more scalable/complex orphan inode handling it's going to take longer to implement O_TMPFILE support for them.... Cheers, Dave. -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 2013-07-22 1:25 ` Dave Chinner @ 2013-07-22 4:06 ` Al Viro 2013-07-24 3:22 ` Dave Chinner 0 siblings, 1 reply; 71+ messages in thread From: Al Viro @ 2013-07-22 4:06 UTC (permalink / raw) To: Dave Chinner; +Cc: Linus Torvalds, Linux Kernel Mailing List On Mon, Jul 22, 2013 at 11:25:17AM +1000, Dave Chinner wrote: > I'll just point out that it can make the whole thing worse, too. > For example, for ext3/4, the tmpfile being created has to be added > to the orphan inode list which is protected by a filesystem global > mutex. Hence scalability of O_TMPFILE is massively limited on > ext3/ext4 due to architectural issues within ext3/4. Other > filesystems will be more efficient, but because they have more > scalable/complex orphan inode handling it's going to take longer to > implement O_TMPFILE support for them.... Um... You do realize that the same architectural issues there will create exactly the same serialization when you are unlinking the sucker? I.e. with the "pick the name, create and open, unlink" sequence ext[34] will insert that inode into the same orphan list, creating the same contention... ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 2013-07-22 4:06 ` Al Viro @ 2013-07-24 3:22 ` Dave Chinner 0 siblings, 0 replies; 71+ messages in thread From: Dave Chinner @ 2013-07-24 3:22 UTC (permalink / raw) To: Al Viro; +Cc: Linus Torvalds, Linux Kernel Mailing List On Mon, Jul 22, 2013 at 05:06:01AM +0100, Al Viro wrote: > On Mon, Jul 22, 2013 at 11:25:17AM +1000, Dave Chinner wrote: > > > I'll just point out that it can make the whole thing worse, too. > > For example, for ext3/4, the tmpfile being created has to be added > > to the orphan inode list which is protected by a filesystem global > > mutex. Hence scalability of O_TMPFILE is massively limited on > > ext3/ext4 due to architectural issues within ext3/4. Other > > filesystems will be more efficient, but because they have more > > scalable/complex orphan inode handling it's going to take longer to > > implement O_TMPFILE support for them.... > > Um... You do realize that the same architectural issues there will > create exactly the same serialization when you are unlinking the > sucker? I.e. with the "pick the name, create and open, unlink" sequence > ext[34] will insert that inode into the same orphan list, creating > the same contention... Yup. But that is assuming that the unlink of the tmpfile happens immediately after the open() and that's not necessarily the case for all users of tmp files that might get converted to use O_TMPFILE, and so a saying it is more efficient than traditional tmpfiles is not necessarily correct. Let's set expectations appropriately at the start, rather than have people complain a year down the track that O_TMPFILE causes them performance problems because they don't understand the limitations of the implementations underlying it...... Cheers, Dave. -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 2013-07-21 19:53 Linux 3.11-rc2 Linus Torvalds ` (2 preceding siblings ...) 2013-07-22 1:25 ` Dave Chinner @ 2013-07-23 1:04 ` rydberg 2013-07-23 1:17 ` Myklebust, Trond 3 siblings, 1 reply; 71+ messages in thread From: rydberg @ 2013-07-23 1:04 UTC (permalink / raw) To: Trond Myklebust, Linus Torvalds; +Cc: Linux Kernel Mailing List Hi Trond, Linus, On Sun, Jul 21, 2013 at 12:53:10PM -0700, Linus Torvalds wrote: > So it's been another week, and -rc2 is out there. This one happens to break nfs in a rather blunt-instrument fashion - creating files on a nfs4 partition [1] no longer works. Bisection yields this commit as the culprit: commit b4a2cf76ab7c08628c62b2062dacefa496b59dfd Author: Trond Myklebust <Trond.Myklebust@netapp.com> Date: Wed Jul 17 16:43:16 2013 -0400 NFSv4: Fix a regression against the FreeBSD server Technically, the Linux client is allowed by the NFSv4 spec to send 3 word bitmaps as part of an OPEN request. However, this causes the current FreeBSD server to return NFS4ERR_ATTRNOTSUPP errors. Fix the regression by making the Linux client use a 2 word bitmap unless doing NFSv4.2 with labeled NFS. Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com> Reverting the patch returns things to normal. Thanks, Henrik [1] type nfs4 (rw,relatime,vers=4.0,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.0.10,local_lock=none,addr=192.168.0.142) ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 2013-07-23 1:04 ` rydberg @ 2013-07-23 1:17 ` Myklebust, Trond 2013-07-23 18:31 ` Myklebust, Trond 0 siblings, 1 reply; 71+ messages in thread From: Myklebust, Trond @ 2013-07-23 1:17 UTC (permalink / raw) To: rydberg; +Cc: Linus Torvalds, Linux Kernel Mailing List [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1444 bytes --] On Tue, 2013-07-23 at 03:04 +0200, rydberg@euromail.se wrote: > Hi Trond, Linus, > > On Sun, Jul 21, 2013 at 12:53:10PM -0700, Linus Torvalds wrote: > > So it's been another week, and -rc2 is out there. > > This one happens to break nfs in a rather blunt-instrument fashion - > creating files on a nfs4 partition [1] no longer works. Bisection > yields this commit as the culprit: > > commit b4a2cf76ab7c08628c62b2062dacefa496b59dfd > Author: Trond Myklebust <Trond.Myklebust@netapp.com> > Date: Wed Jul 17 16:43:16 2013 -0400 > > NFSv4: Fix a regression against the FreeBSD server > > Technically, the Linux client is allowed by the NFSv4 spec to send > 3 word bitmaps as part of an OPEN request. However, this causes the > current FreeBSD server to return NFS4ERR_ATTRNOTSUPP errors. > > Fix the regression by making the Linux client use a 2 word bitmap unless > doing NFSv4.2 with labeled NFS. > > Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com> > > Reverting the patch returns things to normal. - Can you please provide me with a binary tcpdump or wireshark dump that demonstrates the problem? - What server is this? -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@netapp.com www.netapp.com ÿôèº{.nÇ+·®+%Ëÿ±éݶ\x17¥wÿº{.nÇ+·¥{±þG«éÿ{ayº\x1dÊÚë,j\a¢f£¢·hïêÿêçz_è®\x03(éÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?¨èÚ&£ø§~á¶iOæ¬z·vØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?I¥ ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 2013-07-23 1:17 ` Myklebust, Trond @ 2013-07-23 18:31 ` Myklebust, Trond 2013-07-23 19:08 ` rydberg 0 siblings, 1 reply; 71+ messages in thread From: Myklebust, Trond @ 2013-07-23 18:31 UTC (permalink / raw) To: rydberg; +Cc: Linus Torvalds, Linux Kernel Mailing List, Andre Heider [-- Attachment #1: Type: text/plain, Size: 1588 bytes --] On Mon, 2013-07-22 at 21:17 -0400, Trond Myklebust wrote: > On Tue, 2013-07-23 at 03:04 +0200, rydberg@euromail.se wrote: > > Hi Trond, Linus, > > > > On Sun, Jul 21, 2013 at 12:53:10PM -0700, Linus Torvalds wrote: > > > So it's been another week, and -rc2 is out there. > > > > This one happens to break nfs in a rather blunt-instrument fashion - > > creating files on a nfs4 partition [1] no longer works. Bisection > > yields this commit as the culprit: > > > > commit b4a2cf76ab7c08628c62b2062dacefa496b59dfd > > Author: Trond Myklebust <Trond.Myklebust@netapp.com> > > Date: Wed Jul 17 16:43:16 2013 -0400 > > > > NFSv4: Fix a regression against the FreeBSD server > > > > Technically, the Linux client is allowed by the NFSv4 spec to send > > 3 word bitmaps as part of an OPEN request. However, this causes the > > current FreeBSD server to return NFS4ERR_ATTRNOTSUPP errors. > > > > Fix the regression by making the Linux client use a 2 word bitmap unless > > doing NFSv4.2 with labeled NFS. > > > > Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com> > > > > Reverting the patch returns things to normal. > > - Can you please provide me with a binary tcpdump or wireshark dump that > demonstrates the problem? > > - What server is this? OK. With Andre's help, I think we've root caused the problem. Can you please confirm that the attached patch also solves the issue for you? -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@netapp.com www.netapp.com [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-NFSv4-Fix-brainfart-in-attribute-length-calculation.patch --] [-- Type: text/x-patch; name="0001-NFSv4-Fix-brainfart-in-attribute-length-calculation.patch", Size: 1009 bytes --] From 1f84e4f9ef9fc4ff502c112df049dfa6f656f4e0 Mon Sep 17 00:00:00 2001 From: Trond Myklebust <Trond.Myklebust@netapp.com> Date: Tue, 23 Jul 2013 12:53:39 -0400 Subject: [PATCH] NFSv4: Fix brainfart in attribute length calculation The calculation of the attribute length was 4 bytes off. Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com> Tested-by: Andre Heider <a.heider@gmail.com> --- fs/nfs/nfs4xdr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/nfs/nfs4xdr.c b/fs/nfs/nfs4xdr.c index c74d616..3850b01 100644 --- a/fs/nfs/nfs4xdr.c +++ b/fs/nfs/nfs4xdr.c @@ -1118,11 +1118,11 @@ static void encode_attrs(struct xdr_stream *xdr, const struct iattr *iap, len, ((char *)p - (char *)q) + 4); BUG(); } - len = (char *)p - (char *)q - (bmval_len << 2); *q++ = htonl(bmval0); *q++ = htonl(bmval1); if (bmval_len == 3) *q++ = htonl(bmval2); + len = (char *)p - (char *)(q + 1); *q = htonl(len); /* out: */ -- 1.8.3.1 ^ permalink raw reply related [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 2013-07-23 18:31 ` Myklebust, Trond @ 2013-07-23 19:08 ` rydberg 2013-07-23 20:42 ` Linus Torvalds 0 siblings, 1 reply; 71+ messages in thread From: rydberg @ 2013-07-23 19:08 UTC (permalink / raw) To: Myklebust, Trond; +Cc: Linus Torvalds, Linux Kernel Mailing List, Andre Heider Hi Trond, > OK. With Andre's help, I think we've root caused the problem. Can you > please confirm that the attached patch also solves the issue for you? Seems to work fine, Reported-and-tested-by: Henrik Rydberg <rydberg@euromail.se> Thanks, Henrik ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 2013-07-23 19:08 ` rydberg @ 2013-07-23 20:42 ` Linus Torvalds 2013-07-23 20:52 ` Myklebust, Trond 0 siblings, 1 reply; 71+ messages in thread From: Linus Torvalds @ 2013-07-23 20:42 UTC (permalink / raw) To: Henrik Rydberg; +Cc: Myklebust, Trond, Linux Kernel Mailing List, Andre Heider On Tue, Jul 23, 2013 at 12:08 PM, <rydberg@euromail.se> wrote: > Hi Trond, > >> OK. With Andre's help, I think we've root caused the problem. Can you >> please confirm that the attached patch also solves the issue for you? > > Seems to work fine, > > Reported-and-tested-by: Henrik Rydberg <rydberg@euromail.se> Trond, do you have anything else pending and are planning a git pull, or should I just take this patch directly? Linus ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Linux 3.11-rc2 2013-07-23 20:42 ` Linus Torvalds @ 2013-07-23 20:52 ` Myklebust, Trond 0 siblings, 0 replies; 71+ messages in thread From: Myklebust, Trond @ 2013-07-23 20:52 UTC (permalink / raw) To: Linus Torvalds; +Cc: Henrik Rydberg, Linux Kernel Mailing List, Andre Heider [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 904 bytes --] On Tue, 2013-07-23 at 13:42 -0700, Linus Torvalds wrote: > On Tue, Jul 23, 2013 at 12:08 PM, <rydberg@euromail.se> wrote: > > Hi Trond, > > > >> OK. With Andre's help, I think we've root caused the problem. Can you > >> please confirm that the attached patch also solves the issue for you? > > > > Seems to work fine, > > > > Reported-and-tested-by: Henrik Rydberg <rydberg@euromail.se> > > Trond, do you have anything else pending and are planning a git pull, > or should I just take this patch directly? Nothing else queued for now, so if you could take it directly, then that would save the trouble of setting up an extra pull. Thanks! -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@netapp.com www.netapp.com ÿôèº{.nÇ+·®+%Ëÿ±éݶ\x17¥wÿº{.nÇ+·¥{±þG«éÿ{ayº\x1dÊÚë,j\a¢f£¢·hïêÿêçz_è®\x03(éÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?¨èÚ&£ø§~á¶iOæ¬z·vØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?I¥ ^ permalink raw reply [flat|nested] 71+ messages in thread
end of thread, other threads:[~2013-08-04 22:15 UTC | newest] Thread overview: 71+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-07-21 19:53 Linux 3.11-rc2 Linus Torvalds 2013-07-21 21:07 ` Tobias Klausmann 2013-07-22 13:08 ` Rafael J. Wysocki 2013-07-22 15:43 ` Tobias Klausmann 2013-07-21 23:08 ` James Hogan 2013-07-22 13:02 ` Rafael J. Wysocki 2013-07-22 13:15 ` Martin Steigerwald 2013-07-22 13:37 ` Rafael J. Wysocki 2013-07-22 18:46 ` Martin Steigerwald 2013-07-22 19:57 ` Rafael J. Wysocki 2013-07-24 5:10 ` Kalle Valo 2013-07-22 13:21 ` James Hogan 2013-07-22 18:11 ` Linus Torvalds 2013-07-22 19:54 ` Rafael J. Wysocki 2013-07-23 18:46 ` Linux 3.11-rc2 (acpi backlight) Kamal Mostafa 2013-07-24 0:05 ` Rafael J. Wysocki 2013-07-24 4:54 ` Steven Newbury 2013-07-24 6:49 ` James Hogan 2013-07-24 7:14 ` Mike Galbraith 2013-07-24 7:19 ` Igor Gnatenko 2013-07-24 7:19 ` Igor Gnatenko 2013-07-24 12:06 ` Rafael J. Wysocki 2013-07-24 11:45 ` Jörg Otte 2013-07-25 13:00 ` Linux 3.11-rc2 (acpi backlight, revert) Rafael J. Wysocki 2013-07-25 13:00 ` Rafael J. Wysocki 2013-07-25 14:13 ` Aaron Lu 2013-07-25 14:43 ` Kamal Mostafa 2013-07-25 14:46 ` Daniel Vetter 2013-07-25 14:46 ` Daniel Vetter 2013-07-25 14:59 ` Kamal Mostafa 2013-07-25 14:52 ` Jörg Otte 2013-07-25 14:52 ` Jörg Otte 2013-07-25 15:52 ` Jörg Otte 2013-07-25 15:52 ` Jörg Otte 2013-07-25 19:14 ` James Hogan 2013-07-25 19:14 ` James Hogan 2013-07-25 19:47 ` Rafael J. Wysocki 2013-07-25 19:47 ` Rafael J. Wysocki 2013-07-26 4:23 ` Joerg Platte 2013-07-26 11:22 ` Igor Gnatenko 2013-07-26 11:22 ` Igor Gnatenko 2013-07-26 7:43 ` Steven Newbury 2013-07-26 7:43 ` Steven Newbury 2013-07-26 12:09 ` Martin Steigerwald 2013-07-26 12:09 ` Martin Steigerwald 2013-07-26 12:40 ` Rafael J. Wysocki 2013-07-26 12:40 ` Rafael J. Wysocki 2013-08-04 19:33 ` Martin Steigerwald 2013-08-04 19:33 ` Martin Steigerwald 2013-08-04 22:15 ` Rafael J. Wysocki 2013-08-04 22:15 ` Rafael J. Wysocki 2013-07-27 5:34 ` Kalle Valo 2013-07-27 12:18 ` Rafael J. Wysocki 2013-07-27 12:18 ` Rafael J. Wysocki 2013-07-22 18:16 ` Linux 3.11-rc2 Matthew Garrett 2013-07-22 19:56 ` Rafael J. Wysocki 2013-07-23 17:47 ` Steven Newbury 2013-07-23 19:51 ` Matthew Garrett 2013-07-23 19:51 ` Matthew Garrett 2013-07-23 21:10 ` Steven Newbury 2013-07-23 21:24 ` Rafael J. Wysocki 2013-07-23 22:49 ` Steven Newbury 2013-07-22 1:25 ` Dave Chinner 2013-07-22 4:06 ` Al Viro 2013-07-24 3:22 ` Dave Chinner 2013-07-23 1:04 ` rydberg 2013-07-23 1:17 ` Myklebust, Trond 2013-07-23 18:31 ` Myklebust, Trond 2013-07-23 19:08 ` rydberg 2013-07-23 20:42 ` Linus Torvalds 2013-07-23 20:52 ` Myklebust, Trond
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.