Bug#865073: linux-image-4.9.0-3-amd64: vgaswitcheroo/noueveau issues on MacBook Pro 5,1: Failure to shut down and re-enable powered-off devices

2017-06-18 Thread J Mo 
Package: src:linux
Version: 4.9.30-1
Severity: normal

Lately I have been testing Linux on an Apple Macbook Pro 5,1. This model, along 
with the rest of the 5-series, has two GPUs: A chipset/IGP NVidia 9400M and a 
discrete NVidia 9600M GT.

In the pursuit of power savings, I've been looking into ways to power off the 
unused GPU. vgaswitcheroo, a very recent addition to linux, let's me do that.

I am able to successfully power-down the unused GPU via an "echo OFF > 
/sys/kernel/debug/vgaswitcheroo/switch" command, but I've noticed some problems 
as a result.

When I power off an unused GPU, the noueveau driver is hanging on 
shutdown/reboot with an error message such as "Xorg failed to idle channel 2".

There are some similar bugs/reports here. Could be the same issue:
https://bugs.freedesktop.org/show_bug.cgi?id=99889
https://bugs.freedesktop.org/show_bug.cgi?id=94725

Not sure if this should be fixed in noueveau or vgaswitcheroo.

I also note that there is a second issue is that if I send an OFF to power off 
an unused GPU, then suspend the system, come back, and try to turn it back ON 
again, this will fail and the kernel will usually lock up after a little bit. 
If I try to turn the unused GPU back ON again without a suspend in between, it 
works.




-- Package-specific info:
** Version:
Linux version 4.9.0-3-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-1 (2017-06-04)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.9.0-3-amd64 
root=UUID=2055640b-7d44-4167-b0e3-ef7c5187edef ro

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: Apple Inc.
product_name: MacBookPro5,1
product_version: 1.0
chassis_vendor: Apple Inc.
chassis_version: Mac-F42D86A9
bios_vendor: Apple Inc.
bios_version:MBP51.88Z.007E.B06.1202061253
board_vendor: Apple Inc.
board_name: Mac-F42D86A9
board_version: Proto

** Loaded modules:
rtl8192cu
rtl_usb
rtl8192c_common
rtlwifi
ctr
ccm
sctp_diag
sctp
dccp_diag
dccp
tcp_diag
udp_diag
inet_diag
unix_diag
af_packet_diag
netlink_diag
st
sr_mod
cdrom
lp
parport_pc
rfcomm
xt_multiport
ebtable_filter
ebtables
ip6table_filter
ip6_tables
iptable_filter
bnep
snd_hda_codec_realtek
snd_hda_codec_generic
binfmt_misc
nls_ascii
nls_cp437
vfat
fat
joydev
arc4
applesmc
input_polldev
efi_pstore
coretemp
b43
kvm_intel
kvm
irqbypass
bcma
mac80211
nouveau
pcspkr
cfg80211
mxm_wmi
efivars
wmi
ttm
rng_core
drm_kms_helper
drm
i2c_algo_bit
btusb
btrtl
btbcm
btintel
bluetooth
hid_generic
uvcvideo
rfkill
videobuf2_vmalloc
videobuf2_memops
videobuf2_v4l2
videobuf2_core
evdev
videodev
bcm5974
hid_apple
media
sg
snd_hda_intel
shpchp
snd_hda_codec
snd_hda_core
snd_hwdep
snd_pcm
snd_timer
snd
soundcore
nv_tco
sbs
battery
sbshc
apple_gmux
video
acpi_als
kfifo_buf
ac
industrialio
button
acpi_cpufreq
apple_bl
ppdev
parport
sunrpc
efivarfs
ip_tables
x_tables
autofs4
hid_appleir
usbhid
hid
ext4
crc16
jbd2
fscrypto
mbcache
raid10
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xor
raid6_pq
crc32c_generic
libcrc32c
raid1
raid0
multipath
linear
md_mod
sd_mod
ohci_pci
ahci
libahci
xhci_pci
ehci_pci
xhci_hcd
ohci_hcd
ehci_hcd
firewire_ohci
libata
firewire_core
crc_itu_t
ssb
scsi_mod
mmc_core
pcmcia
pcmcia_core
forcedeth
usbcore
usb_common
i2c_nforce2

** PCI devices:
00:00.0 Host bridge [0600]: NVIDIA Corporation MCP79 Host Bridge [10de:0a82] 
(rev b1)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- 
Kernel driver in use: nForce2_smbus
Kernel modules: i2c_nforce2, nv_tco

00:03.3 RAM memory [0500]: NVIDIA Corporation MCP79 Memory Controller 
[10de:0a89] (rev b1)
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- 
Kernel driver in use: ohci-pci
Kernel modules: ohci_pci

00:04.1 USB controller [0c03]: NVIDIA Corporation MCP79 EHCI USB 2.0 Controller 
[10de:0aa6] (rev b1) (prog-if 20 [EHCI])
Subsystem: NVIDIA Corporation Apple iMac 9,1 [10de:cb79]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci

00:06.0 USB controller [0c03]: NVIDIA Corporation MCP79 OHCI USB 1.1 Controller 
[10de:0aa7] (rev b1) (prog-if 10 [OHCI])
Subsystem: NVIDIA Corporation Apple iMac 9,1 [10de:cb79]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr-

Bug#865071: linux-image-4.9.0-3-amd64: Apple Macbook Pro 5,1: Weird intermittent ACPI problems; battery missing, sensors missing, special keys not working...

2017-06-18 Thread J Mo 
Package: src:linux
Version: 4.9.30-1
Severity: normal

I recently installed Debian on an old Apple Macbook Pro 5,1 from 2009/2010.

The good news is that almost everything works by default. However, I've got a 
weird chronic intermittent problem which I think is related to the kernel and 
ACPI or possibly the apple_smc controller. I'm not really sure WTF is going on.

This issue occurs on approximately 50% of boots. No declarable pattern that 
I've noticed.

Here's a list of symptoms:

Some special top-row keys don't work: LCD backlight adjustment and 
keyboard backlight adjustment. Volume adjustment buttons work fine.

The power button causes the system to immediately powerdown, instead of 
the normal KDE logout screen.

macfanctld (fan speed daemon) fails to start with an error message in 
it's log: "Error: Can't find a applesmc device".

The sysfs battery device goes missing (/sys/class/power_supply/BAT0) 
and thus acpi, upower, KDE Power Management, and everything upwind breaks.

Sometimes some thermal sensors from the applesmc-isa-0300 are missing 
in dmesg/kenerl log.



All of the above can occur in a mixture. I think the most common thing that I'm 
seeing is that the battery device is missing.

Here is what the kernel line for the battery looks like:
kernel: ACPI: Smart Battery System [SBS0]: Battery Slot [BAT0] (battery 
present)

And when things go bad, that line is missing in the boot log.

I've got a bunch of dmesg saves from instances where things are broken, but I 
have not yet noticed any clues about what is going on, except the notable 
absence of things being detected correctly.



Please advise. Should I take this straight upstream to LKML? Anyone specific 
you think I should cc about this before I google it myself?

What info should I be collecting?

On the subject of google: I've searched around and have not found any similar 
reports on this recently.




-- Package-specific info:
** Version:
Linux version 4.9.0-3-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-1 (2017-06-04)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.9.0-3-amd64 
root=UUID=2055640b-7d44-4167-b0e3-ef7c5187edef ro

** Not tainted

** Kernel log:
REMOVED

** Model information
sys_vendor: Apple Inc.
product_name: MacBookPro5,1
product_version: 1.0
chassis_vendor: Apple Inc.
chassis_version: Mac-F42D86A9
bios_vendor: Apple Inc.
bios_version:MBP51.88Z.007E.B06.1202061253
board_vendor: Apple Inc.
board_name: Mac-F42D86A9
board_version: Proto

** Loaded modules:
ctr
ccm
sctp_diag
sctp
dccp_diag
dccp
tcp_diag
udp_diag
inet_diag
unix_diag
af_packet_diag
netlink_diag
st
sr_mod
cdrom
lp
parport_pc
rfcomm
xt_multiport
ebtable_filter
ebtables
ip6table_filter
ip6_tables
iptable_filter
bnep
snd_hda_codec_realtek
snd_hda_codec_generic
binfmt_misc
nls_ascii
nls_cp437
vfat
fat
joydev
arc4
applesmc
input_polldev
efi_pstore
coretemp
b43
kvm_intel
kvm
irqbypass
bcma
mac80211
nouveau
pcspkr
cfg80211
mxm_wmi
efivars
wmi
ttm
rng_core
drm_kms_helper
drm
i2c_algo_bit
btusb
btbcm
btintel
bluetooth
hid_generic
uvcvideo
rfkill
videobuf2_vmalloc
videobuf2_memops
videobuf2_v4l2
videobuf2_core
evdev
videodev
bcm5974
hid_apple
media
sg
snd_hda_intel
shpchp
snd_hda_codec
snd_hda_core
snd_hwdep
snd_pcm
snd_timer
snd
soundcore
nv_tco
sbs
battery
sbshc
apple_gmux
video
acpi_als
kfifo_buf
ac
industrialio
button
acpi_cpufreq
apple_bl
ppdev
parport
sunrpc
efivarfs
ip_tables
x_tables
autofs4
hid_appleir
usbhid
hid
ext4
crc16
jbd2
fscrypto
mbcache
raid10
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xor
raid6_pq
crc32c_generic
libcrc32c
raid1
raid0
multipath
linear
md_mod
sd_mod
ohci_pci
ahci
libahci
xhci_pci
ehci_pci
xhci_hcd
ohci_hcd
ehci_hcd
firewire_ohci
libata
firewire_core
crc_itu_t
ssb
scsi_mod
mmc_core
pcmcia
pcmcia_core
forcedeth
usbcore
usb_common
i2c_nforce2

** PCI devices:
00:00.0 Host bridge [0600]: NVIDIA Corporation MCP79 Host Bridge [10de:0a82] 
(rev b1)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- 
Kernel driver in use: nForce2_smbus
Kernel modules: i2c_nforce2, nv_tco

00:03.3 RAM memory [0500]: NVIDIA Corporation MCP79 Memory Controller 
[10de:0a89] (rev b1)
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- 
Kernel driver in use: ohci-pci
Kernel modules: ohci_pci

00:04.1 USB controller [0c03]: NVIDIA Corporation MCP79 EHCI USB 2.0 Controller 
[10de:0aa6] (rev b1) (prog-if 20 [EHCI])
Subsystem: NVIDIA Corporation Apple iMac 9,1 [10de:cb79]
Control: I/O- Mem+ BusMaster+ SpecCycle-

Uploading linux (4.11.6-1)

2017-06-18 Thread Ben Hutchings 
I intend to upload linux version 4.11.6-1 to unstable on Monday.
As this is a new upstream version, there is of course an ABI bump.

Some of the changes:

  * [amd64] Enable LEGACY_VSYSCALL_NONE instead of LEGACY_VSYSCALL_EMULATE
  * [arm64] Enable support for Meson platform
  * debian/control: Fix compiler build-dependencies for cross-building
  * [armel] Adjust configuration to reduce image size (fixes FTBFS)
  * netfilter: Enable NF_SOCKET_IPV4, NF_SOCKET_IPV6 as modules
  * Enable BUG_ON_DATA_CORRUPTION
  * [arm64,x86] Replace securelevel patch set with lockdown patch set
  * [arm64] Enable support for Allwinner sunxi platform
  * [arm64] Enable REGULATOR_GPIO as module
  * block: Enable BLK_WBT, BLK_WBT_MQ
  * usbip: Fix FTBFS on 64-bit architectures with gcc-7
  * [m68k] udeb updates from John Paul Adrian Glaubitz
  * [x86] Enable SERIAL_8250_MID as built-in
  * debian/rules.real: Include rules.defs before using architecture variables
  * [rt] Update to 4.11.5-rt1 and reenable
  * fs: Reenable HPFS_FS as module
  * USB: serial: option: add two Longcheer device ids
  * [armhf] PCI: Enable PCI_HOST_GENERIC

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.



signature.asc
Description: This is a digitally signed message part

Processed: Re: Bug#846941: linux-image-4.8.0-1-amd64-unsigned: ThinkPad X220: hibernating with screen turned off (screensaver) causes it to remain off until reboot

2017-06-18 Thread Debian Bug Tracking System 
Processing control commands:

> retitle -1 ThinkPad X220: suspending or hibernating with screen turned off 
> causes it to remain off until reboot
Bug #846941 [src:linux] linux-image-4.8.0-1-amd64-unsigned: ThinkPad X220: 
hibernating with screen turned off (screensaver) causes it to remain off until 
reboot
Changed Bug title to 'ThinkPad X220: suspending or hibernating with screen 
turned off causes it to remain off until reboot' from 
'linux-image-4.8.0-1-amd64-unsigned: ThinkPad X220: hibernating with screen 
turned off (screensaver) causes it to remain off until reboot'.
> notfound -1 linux/3.16+63
Bug #846941 [src:linux] ThinkPad X220: suspending or hibernating with screen 
turned off causes it to remain off until reboot
The source linux and version 3.16+63 do not appear to match any binary packages
Ignoring request to alter found versions of bug #846941 to the same values 
previously set
> found -1 linux/4.9+80
Bug #846941 [src:linux] ThinkPad X220: suspending or hibernating with screen 
turned off causes it to remain off until reboot
The source linux and version 4.9+80 do not appear to match any binary packages
Marked as found in versions linux/4.9+80.

-- 
846941: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846941
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#846941: linux-image-4.8.0-1-amd64-unsigned: ThinkPad X220: hibernating with screen turned off (screensaver) causes it to remain off until reboot

2017-06-18 Thread Benjamin Barenblat 
Control: retitle -1 ThinkPad X220: suspending or hibernating with screen turned 
off causes it to remain off until reboot
Control: notfound -1 linux/3.16+63
Control: found -1 linux/4.9+80

On Sun, Dec  4, 2016 at  5:02:52 PM, Ivan Krylov  wrote:
> When I hibernate my machine with screen turned on
> (e.g. xfce4-session-logout --hibernate), it wakes up as expected.
> However, if something turns the screen off before that
> (e.g. XScreenSaver activating), on wakeup the screen is unresponsive,
> but the remaining system works (I can ssh into machine and play music,
> etc).

I can reproduce this on my X220 tablet with linux-image-4.9.0-3-amd64.

  1. Run `xset dpms force off` to shut the display off.
  2. Close the lid, suspending the machine.
  3. Reopen the lid, bringing the machine back up.

At this point, the display is off and will remain so until I reboot. The
machine is otherwise functional; if I leave a terminal open before
running these steps, I can type `systemctl reboot`, and the system will
reboot.

Bug#864453: fanotify07 LTP testcase hangs process

2017-06-18 Thread Ben Hutchings 
On Sun, 2017-06-18 at 10:40 +0200, Helge Deller wrote:
> On 12.06.2017 16:58, Ben Hutchings wrote:
> > On Thu, 2017-06-08 at 21:23 +0200, Helge Deller wrote:
> > > Can you backport at least the commit 05f0e38724e8 ?
> > 
> > This appears to depend on commit 9385a84d7e1f which looks hard to backport.
> 
> Ben, if it's too much work, maybe just don't do it.
> I think the upstream maintainer wrote something in his commit
> message that fixing this issue in backports might be hard/impossible.
> 
> When running the testsuite, the kernel additionally reported that processes
> may hang, and tainted itself accordingly. Sadly I don't have the
> exact kernel message at hand right now.

That's a Debian-specific warning for use of fanotify permission
checking, which I suspect this test would always trigger.

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.


signature.asc
Description: This is a digitally signed message part

Bug#864453: fanotify07 LTP testcase hangs process

2017-06-18 Thread Helge Deller 
On 12.06.2017 16:58, Ben Hutchings wrote:
> On Thu, 2017-06-08 at 21:23 +0200, Helge Deller wrote:
>> Can you backport at least the commit 05f0e38724e8 ?
> 
> This appears to depend on commit 9385a84d7e1f which looks hard to backport.

Ben, if it's too much work, maybe just don't do it.
I think the upstream maintainer wrote something in his commit
message that fixing this issue in backports might be hard/impossible.

When running the testsuite, the kernel additionally reported that processes
may hang, and tainted itself accordingly. Sadly I don't have the
exact kernel message at hand right now.

Helge