Kernel disabling serial port ttyS0 again

[Hans109h]

Upon upgrading from 14.10 to Ubuntu Gnome 15.10 with kernel 4.2 I am once again unable to access my serial port.

ProblemType: Bug
DistroRelease: Ubuntu 15.10
Package: linux-image-4.2.0-16-generic 4.2.0-16.19
ProcVersionSignature: Ubuntu 4.2.0-16.19-generic 4.2.3
Uname: Linux 4.2.0-16-generic x86_64
ApportVersion: 2.19.1-0ubuntu3
Architecture: amd64
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/pcmC1D0c', '/dev/snd/controlC1', '/dev/snd/by-path', '/dev/snd/hwC0D3', '/dev/snd/hwC0D0', '/dev/snd/pcmC0D7p', '/dev/snd/pcmC0D3p', '/dev/snd/pcmC0D2c', '/dev/snd/pcmC0D1p', '/dev/snd/pcmC0D0c', '/dev/snd/pcmC0D0p', '/dev/snd/controlC0', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
Date: Sat Oct 24 22:50:11 2015
HibernationDevice: RESUME=UUID=61ccfbf9-f4d0-4989-8d82-be0dd1500450
InstallationDate: Installed on 2014-11-30 (328 days ago)
InstallationMedia: Ubuntu-GNOME 14.10 "Utopic Unicorn" - Release amd64 (20141022.1)
MachineType: System manufacturer System Product Name
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.2.0-16-generic root=UUID=e0e80586-764e-42bf-8659-c5da430f1d1e ro crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M
PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon.
RelatedPackageVersions:
 linux-restricted-modules-4.2.0-16-generic N/A
 linux-backports-modules-4.2.0-16-generic N/A
 linux-firmware 1.149
RfKill:
 0: phy0: Wireless LAN
  Soft blocked: yes
  Hard blocked: no
SourcePackage: linux
UpgradeStatus: Upgraded to wily on 2015-10-24 (0 days ago)
dmi.bios.date: 08/13/2013
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 2104
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: P8Z77-V
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: Rev 1.xx
dmi.chassis.asset.tag: Asset-1234567890
dmi.chassis.type: 3
dmi.chassis.vendor: Chassis Manufacture
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr2104:bd08/13/2013:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnP8Z77-V:rvrRev1.xx:cvnChassisManufacture:ct3:cvrChassisVersion:
dmi.product.name: System Product Name
dmi.product.version: System Version
dmi.sys.vendor: System manufacturer

[Brad Figg (brad-figg)]

This change was made by a bot.

[penalvch (penalvch)]

Hans109h, thank you for reporting this and helping make Ubuntu better.

Could you please test the latest mainline kernel (4.3-rc7) and advise to the results?

[Hans109h (hans109h)]

I have tested the mainline kernel, v4.3-rc6-unstable and the bug is still present.

[penalvch (penalvch)]

Hans109h, the next step is to fully commit bisect from kernel 3.16 to 4.2 in order to identify the last good kernel commit, followed immediately by the first bad one. This will allow for a more expedited analysis of the root cause of your issue. Could you please do this following https://wiki.ubuntu.com/Kernel/KernelBisection ?

Please note, finding adjacent kernel versions is not fully commit bisecting.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[Hans109h (hans109h)]

Adjacent kernel versions:

Good: 3.19.0-22.22
Bad: 4.0.0-1.1

Working on commit bisect.

[Hans109h (hans109h)]

c420dbd13ef7f399a865498496ac9ce2755b8007 is the first bad commit
commit c420dbd13ef7f399a865498496ac9ce2755b8007
Author: Thomas Gleixner <email address hidden>
Date: Mon Feb 2 10:42:48 2015 +0800

    ACPI: Implement proper length checks for mem resources

    Check whether the resulting length is the same as the given
    length. Check for start <= end as well.

    We need to hand in the resource for this, so we can apply the flags
    directly.

    [Jiang] Remove enforcement that resource starting address must be
    non-zero.

    Signed-off-by: Thomas Gleixner <email address hidden>
    Signed-off-by: Jiang Liu <email address hidden>
    Signed-off-by: Rafael J. Wysocki <email address hidden>

:040000 040000 8cb7699fc3d3b9498cd76d13a2f5edd1b40e6c40 6602fafdd7d25b91781ce211a01e6c73a22585c4 M drivers

[Hans109h (hans109h)]

No change, v4.3-rc7 is bad.

[penalvch (penalvch)]

Hans109h, the issue you are reporting is an upstream one. Could you please report this problem following the instructions verbatim at https://wiki.ubuntu.com/Bugs/Upstream/kernel to the appropriate venue (Rafael J. Wysocki, Len Brown, Thomas Gleixner, Jiang Liu, and Rafael J. Wysocki, CC linux-acpi)?

Please provide a direct URL to your newly made report when it becomes available so that it may be tracked.

Thank you for your understanding.

[Hans109h (hans109h)]

A recent commit has fixed this problem upstream. I need to bisect still, just keeping some notes here.

Fixed prior to commit 5807fcaa9bf7dd87241df739161c119cf78a6bc4 but after v4.4.0

[Hans109h (hans109h)]

fix after afd2ff9b7e1b367172f18ba7f693dfb62bdcb2dc

[Hans109h (hans109h)]

e0f03e87fc6f27a8af9896f430f2945b3b1664c0 is the first bad commit
commit e0f03e87fc6f27a8af9896f430f2945b3b1664c0
Author: Heiner Kallweit <email address hidden>
Date: Wed Dec 16 07:33:22 2015 +0100

    PNP: respect PNP_DRIVER_RES_DO_NOT_CHANGE when detaching

    I have a device (Nuvoton 6779D Super-IO IR RC with nuvoton-cir driver)
    which works after initial boot but not any longer if I unload and
    re-load the driver module.

    Digging into the issue I found that unloading the driver calls
    pnp_disable_dev although the driver has flag PNP_DRIVER_RES_DO_NOT_CHANGE
    set. IMHO this is not right.

    Let's have a look at the call chain when probing a device:
    pnp_device_probe
    1. attaches the device
    2. if it's not active and PNP_DRIVER_RES_DO_NOT_CHANGE is not set
       it gets activated
    3. probes driver

    I think pnp_device_remove should do it in reverse order and also
    respect PNP_DRIVER_RES_DO_NOT_CHANGE. Therefore:
    1. call drivers remove callback
    2. if device is active and PNP_DRIVER_RES_DO_NOT_CHANGE is not set
       disable it
    3. detach device

    The change works for me and sounds logical to me.
    However I don't know the pnp driver in detail so I might be wrong.

    Signed-off-by: Heiner Kallweit <email address hidden>
    Signed-off-by: Rafael J. Wysocki <email address hidden>

:040000 040000 8b208d9346c4a3948dbf8cde3083cc9c8adb026d 2f91a8f9fcf0699cc5d8ea3bc4322d8f1724e67b M drivers