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
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
On 21 July 2013 20:53, Linus Torvalds <[email protected]> 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
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
[email protected]
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...
On Monday, July 22, 2013 12:08:40 AM James Hogan wrote:
> On 21 July 2013 20:53, Linus Torvalds <[email protected]> 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)
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.
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 <[email protected]>
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
On 22 July 2013 14:02, Rafael J. Wysocki <[email protected]> wrote:
> On Monday, July 22, 2013 12:08:40 AM James Hogan wrote:
>> On 21 July 2013 20:53, Linus Torvalds <[email protected]> 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
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 <[email protected]>
> 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.
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
On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <[email protected]> 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
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 | [email protected]
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
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 <[email protected]>
> >
> > 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
On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
> On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki <[email protected]> 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
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
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 <[email protected]>
> > >
> > > 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
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 <[email protected]>
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 <[email protected]>
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)
On Tue, 2013-07-23 at 03:04 +0200, [email protected] 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 <[email protected]>
> 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 <[email protected]>
>
> 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
[email protected]
http://www.netapp.com
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
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
On Mon, 2013-07-22 at 21:17 -0400, Trond Myklebust wrote:
> On Tue, 2013-07-23 at 03:04 +0200, [email protected] 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 <[email protected]>
> > 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 <[email protected]>
> >
> > 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
[email protected]
http://www.netapp.com
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 <[email protected]> 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
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 <[email protected]>
Thanks,
Henrik
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 | [email protected]
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
On Tue, Jul 23, 2013 at 12:08 PM, <[email protected]> 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 <[email protected]>
Trond, do you have anything else pending and are planning a git pull,
or should I just take this patch directly?
Linus
On Tue, 2013-07-23 at 13:42 -0700, Linus Torvalds wrote:
> On Tue, Jul 23, 2013 at 12:08 PM, <[email protected]> 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 <[email protected]>
>
> 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
[email protected]
http://www.netapp.com
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
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.
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
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! ;-)
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 <[email protected]> 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.
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
[email protected]
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 <[email protected]> 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.
"Rafael J. Wysocki" <[email protected]> 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
On 24 July 2013 01:05, Rafael J. Wysocki <[email protected]> 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
On Wed, 2013-07-24 at 07:49 +0100, James Hogan wrote:
> On 24 July 2013 01:05, Rafael J. Wysocki <[email protected]> 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
On Wed, 2013-07-24 at 07:49 +0100, James Hogan wrote:
> On 24 July 2013 01:05, Rafael J. Wysocki <[email protected]> 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
2013/7/24 Rafael J. Wysocki <[email protected]>:
> 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 <[email protected]> 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:
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 <[email protected]> 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.
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 <[email protected]> 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 <[email protected]>
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 <[email protected]>
Reported-by: Steven Newbury <[email protected]>
Reported-by: Kamal Mostafa <[email protected]>
Reported-by: Martin Steigerwald <[email protected]>
Reported-by: Jörg Otte <[email protected]>
Reported-by: Kalle Valo <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
---
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_ */
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 <[email protected]> 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 <[email protected]>
> 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 <[email protected]>
> Reported-by: Steven Newbury <[email protected]>
> Reported-by: Kamal Mostafa <[email protected]>
> Reported-by: Martin Steigerwald <[email protected]>
> Reported-by: Jörg Otte <[email protected]>
> Reported-by: Kalle Valo <[email protected]>
> Signed-off-by: Rafael J. Wysocki <[email protected]>
> ---
> 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_ */
>
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 <[email protected]> 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
2013/7/25 Rafael J. Wysocki <[email protected]>:
> 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 <[email protected]> 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
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 <[email protected]> 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
2013/7/25 Jörg Otte <[email protected]>:
> 2013/7/25 Rafael J. Wysocki <[email protected]>:
>> 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 <[email protected]> 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
On 25 July 2013 14:00, Rafael J. Wysocki <[email protected]> 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 <[email protected]> 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
On Thursday, July 25, 2013 08:14:08 PM James Hogan wrote:
> On 25 July 2013 14:00, Rafael J. Wysocki <[email protected]> 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 <[email protected]> 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.
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
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 <[email protected]> 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 <[email protected]>
> 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 <[email protected]>
By the way, I'm willing to test any i915 backlight patches if it helps.
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 <[email protected]> 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 <[email protected]> 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
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 <[email protected]> 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
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 <[email protected]> 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.
"Rafael J. Wysocki" <[email protected]> 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 <[email protected]>
--
Kalle Valo
On Saturday, July 27, 2013 08:34:13 AM Kalle Valo wrote:
> "Rafael J. Wysocki" <[email protected]> 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 <[email protected]>
Thanks a lot for the confirmation, this already is in the Linus' tree.
Rafael
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 <[email protected]>
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
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 <[email protected]>
> 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!