Le mer. 12 févr. 2014 15:04:28 CET, Rafael J. Wysocki a écrit :
>>> Mika, I'll add a changelog to your patch and queue it up as a fix for 3.14.
>>>
>>
>> Thanks guys for solving this issue !
>>
>> Rafael, could this be submitted to stable trees (at least 3.12, 3.13) as
>> well ?
>
> Yes, I have mar
On Wednesday, February 12, 2014 08:44:13 AM Francis Moreau wrote:
> On 02/12/2014 12:58 AM, Rafael J. Wysocki wrote:
> > On Tuesday, February 11, 2014 07:17:37 PM Peter Wu wrote:
> >> On Tuesday 11 February 2014 12:42:37 Mika Westerberg wrote:
> >>> On Mon, Feb 10, 2014 at 11:39:29PM +0100, Rafael
On Wed, Feb 12, 2014 at 12:58:07AM +0100, Rafael J. Wysocki wrote:
> Mika, I'll add a changelog to your patch and queue it up as a fix for 3.14.
Thanks Rafael.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majo
On 02/12/2014 12:58 AM, Rafael J. Wysocki wrote:
> On Tuesday, February 11, 2014 07:17:37 PM Peter Wu wrote:
>> On Tuesday 11 February 2014 12:42:37 Mika Westerberg wrote:
>>> On Mon, Feb 10, 2014 at 11:39:29PM +0100, Rafael J. Wysocki wrote:
> _STA() returns 0x0A instead of 0x0F. Could there b
On Tuesday, February 11, 2014 07:17:37 PM Peter Wu wrote:
> On Tuesday 11 February 2014 12:42:37 Mika Westerberg wrote:
> > On Mon, Feb 10, 2014 at 11:39:29PM +0100, Rafael J. Wysocki wrote:
> > > > _STA() returns 0x0A instead of 0x0F. Could there be something missing in
> > > > the ACPI hotplug co
On Tuesday 11 February 2014 12:42:37 Mika Westerberg wrote:
> On Mon, Feb 10, 2014 at 11:39:29PM +0100, Rafael J. Wysocki wrote:
> > > _STA() returns 0x0A instead of 0x0F. Could there be something missing in
> > > the ACPI hotplug code that overlooks this and removes the device on
> > > resume?
> >
Le 09/02/2014 23:07, Peter Wu a écrit :
> I think this is relevant. See also my test with 3.13.2 and different
> kernel configs[1]. A workaround that triggers a scan was also posted[2].
>
> Peter
>
> [1]: http://lkml.org/lkml/2014/2/8/264
> [2]: http://lkml.org/lkml/2014/2/7/809
Thanks, I can
On Tuesday, February 11, 2014 12:42:37 PM Mika Westerberg wrote:
> On Mon, Feb 10, 2014 at 11:39:29PM +0100, Rafael J. Wysocki wrote:
> > > _STA() returns 0x0A instead of 0x0F. Could there be something missing in
> > > the ACPI hotplug code that overlooks this and removes the device on
> > > resum
On Mon, Feb 10, 2014 at 11:39:29PM +0100, Rafael J. Wysocki wrote:
> > _STA() returns 0x0A instead of 0x0F. Could there be something missing in
> > the ACPI hotplug code that overlooks this and removes the device on resume?
>
> That is possible. Actually even quite likely, but let's wait for the
On Monday, February 10, 2014 02:20:35 PM Mika Westerberg wrote:
> On Mon, Feb 10, 2014 at 01:10:19PM +0100, Rafael J. Wysocki wrote:
> > On Monday, February 10, 2014 02:15:22 AM Peter Wu wrote:
> > > On Monday 10 February 2014 01:52:14 Rafael J. Wysocki wrote:
> > > > > Could the following commit h
On Mon, Feb 10, 2014 at 01:10:19PM +0100, Rafael J. Wysocki wrote:
> On Monday, February 10, 2014 02:15:22 AM Peter Wu wrote:
> > On Monday 10 February 2014 01:52:14 Rafael J. Wysocki wrote:
> > > > Could the following commit have something to do with it?
> > > >
> > > >
> > > >
> > > > commit 4eb
On Monday, February 10, 2014 02:15:22 AM Peter Wu wrote:
> On Monday 10 February 2014 01:52:14 Rafael J. Wysocki wrote:
> > > Could the following commit have something to do with it?
> > >
> > >
> > >
> > > commit 4ebe34503baa0644c9352bcd76d4cf573bffe206
> > > Author: Rafael J. Wysocki
> > > Date
On 02/09/2014 07:44 PM, Bastien Traverse wrote:
> Le 07/02/2014 02:19, Rafael J. Wysocki a écrit :
>> Please send the output of lspci -vv right before suspend and right after
>> the subsequent resume as attachments.
>
> You'll find them attached, but I got a strange error when I wanted to
> run it
On Monday 10 February 2014 01:52:14 Rafael J. Wysocki wrote:
> > Could the following commit have something to do with it?
> >
> >
> >
> > commit 4ebe34503baa0644c9352bcd76d4cf573bffe206
> > Author: Rafael J. Wysocki
> > Date: Tue Jul 16 22:10:35 2013 +0200
> >
> >
> > ACPI / hotplug / PCI:
On Monday, February 10, 2014 12:18:16 AM Peter Wu wrote:
> On Sunday 09 February 2014 22:46:05 Rafael J. Wysocki wrote:
> > That most likely would single out one of the ACPIPHP commits without giving
> > us much clue about what's going on.
> >
> > I fail to see what the connection between those ch
On Sunday 09 February 2014 22:46:05 Rafael J. Wysocki wrote:
> That most likely would single out one of the ACPIPHP commits without giving
> us much clue about what's going on.
>
> I fail to see what the connection between those changes and system resume
> is, however.
>
> Please replace all pr_d
On Sunday 09 February 2014 19:44:27 Bastien Traverse wrote:
> You'll find them attached, but I got a strange error when I wanted to
> run it as root:
> $ sudo lspci -vv > lspci_vv_before
> pcilib: sysfs_read_vpd: read failed: Connection timed out
> $ sudo -i
> # lspci -vv
> pcilib: sysfs_read_vpd:
On Saturday, February 08, 2014 10:34:23 PM Peter Wu wrote:
> On Saturday 08 February 2014 16:01:36 Rafael J. Wysocki wrote:
> > It looks like we fail to resume the device, then, for some reason.
> >
> > That may be a PCIe link issue or something similar.
> >
> > Is this a regression for you? If
On Saturday 08 February 2014 16:01:36 Rafael J. Wysocki wrote:
> It looks like we fail to resume the device, then, for some reason.
>
> That may be a PCIe link issue or something similar.
>
> Is this a regression for you? If so, what's the last kernel that didn't
> have this problem? Does 3.13.
On Friday, February 07, 2014 02:43:03 PM Peter Wu wrote:
> On Friday 07 February 2014 00:48:14 Rafael J. Wysocki wrote:
> > On Friday, February 07, 2014 12:27:03 AM you wrote:
> > [...]
> >
> > > [ 49.170694] video LNXVIDEO:01: Restoring backlight state
> > > [ 49.644845] ACPI: \_SB_.AC__: ACP
On Friday 07 February 2014 00:48:14 Rafael J. Wysocki wrote:
> On Friday, February 07, 2014 12:27:03 AM you wrote:
> [...]
>
> > [ 49.170694] video LNXVIDEO:01: Restoring backlight state
> > [ 49.644845] ACPI: \_SB_.AC__: ACPI_NOTIFY_BUS_CHECK event: unsupported
> > [ 49.646671] jme :04:
On 02/07/2014 12:15 AM, Bastien Traverse wrote:
>
> I was also hit by the rtsx driver bug
> (https://bugs.archlinux.org/task/37720) and was delighted with its fast
> resolution. I was hoping that its fix would also address the
> disappearing Ethernet bug.
yeah, but calling this "fast resolution"
On Friday, February 07, 2014 12:41:44 AM Bastien Traverse wrote:
[...]
> [ 200.934601] ACPI: Waking up from system sleep state S3
> [ 200.993469] xhci_hcd :00:14.0: System wakeup disabled by ACPI
> [ 201.006819] ehci-pci :00:1a.0: System wakeup disabled by ACPI
> [ 201.033495] ehci-pc
On Friday, February 07, 2014 12:27:03 AM you wrote:
[...]
> [ 49.170694] video LNXVIDEO:01: Restoring backlight state
> [ 49.644845] ACPI: \_SB_.AC__: ACPI_NOTIFY_BUS_CHECK event: unsupported
> [ 49.646671] jme :04:00.5: irq 50 for MSI/MSI-X
> [ 49.671645] jme :04:00.5 eth0: Link i
Le 06/02/2014 08:38, Francis Moreau a écrit :
> I'm still leaving with this issue since my initial posting
> unfortunately :(
Damn, I was hoping you'd have found a workaround for this by now. It is
quite severe though!
> I'm wondering why PM support on this machine is so crapish
My quick researc
On Thursday, February 06, 2014 10:08:25 PM Peter Wu wrote:
> On Thursday 06 February 2014 00:42:51 Bastien Traverse wrote:
> > I just used my Ethernet NIC for the first time on an up-to-date
> > Archlinux; it was working fine until I suspended to RAM: on resume the
> > Realtek/Ethernet device had c
On Thursday 06 February 2014 00:42:51 Bastien Traverse wrote:
> I just used my Ethernet NIC for the first time on an up-to-date
> Archlinux; it was working fine until I suspended to RAM: on resume the
> Realtek/Ethernet device had completely disappeared.
>
> The two entries absent from lspci outpu
On 02/06/2014 01:40 PM, Rafael J. Wysocki wrote:
> On Thursday, February 06, 2014 08:38:15 AM Francis Moreau wrote:
>> Hi,
>>
>> On 02/06/2014 12:42 AM, Bastien Traverse wrote:
>>> Hello,
>>>
>>> I'm encountering the exact same problem (same model of machine, same
>>> controller, same OS) and was w
On Thursday, February 06, 2014 08:38:15 AM Francis Moreau wrote:
> Hi,
>
> On 02/06/2014 12:42 AM, Bastien Traverse wrote:
> > Hello,
> >
> > I'm encountering the exact same problem (same model of machine, same
> > controller, same OS) and was wondering where this bug was at.
>
> I'm still leavi
Hi,
On 02/06/2014 12:42 AM, Bastien Traverse wrote:
> Hello,
>
> I'm encountering the exact same problem (same model of machine, same
> controller, same OS) and was wondering where this bug was at.
I'm still leaving with this issue since my initial posting unfortunately :(
I'm wondering why PM
Hello,
I'm encountering the exact same problem (same model of machine, same
controller, same OS) and was wondering where this bug was at.
I just used my Ethernet NIC for the first time on an up-to-date
Archlinux; it was working fine until I suspended to RAM: on resume the
Realtek/Ethernet device
Hello Rafael,
Could you see something in the logs ?
Thanks
On 12/12/2013 08:17 PM, Francis Moreau wrote:
> On 12/12/2013 06:58 PM, Rafael J. Wysocki wrote:
>> On Thursday, December 12, 2013 06:43:03 PM Francis Moreau wrote:
>
> [...]
>
>>>
>>> Actually I can see this now:
>>>
>>> [ 42.400974
On 12/12/2013 06:58 PM, Rafael J. Wysocki wrote:
> On Thursday, December 12, 2013 06:43:03 PM Francis Moreau wrote:
[...]
>>
>> Actually I can see this now:
>>
>> [ 42.400974] r8169 :03:00.2: System wakeup disabled by ACPI
>
> This should be harmless.
>
> Please run lspci -vv before and a
On Thursday, December 12, 2013 06:43:03 PM Francis Moreau wrote:
> Hi Rafael,
>
> On 12/12/2013 03:57 PM, Rafael J. Wysocki wrote:
> > On Thursday, December 12, 2013 09:00:01 AM Francis Moreau wrote:
> >> Hello,
> >>
> >> I'm encountering an issue after resuming my system from suspend to RAM:
> >>
On Thursday, December 12, 2013 09:00:01 AM Francis Moreau wrote:
> Hello,
>
> I'm encountering an issue after resuming my system from suspend to RAM:
> my ethernet controller is missing, it seems that the kernel doesn't see
> it anymore. It's missing from /sys/class/net.
>
> Before suspending, th
On 12/12/2013 09:00 AM, Francis Moreau wrote:
> Hello,
>
> I'm encountering an issue after resuming my system from suspend to RAM:
> my ethernet controller is missing, it seems that the kernel doesn't see
> it anymore. It's missing from /sys/class/net.
>
> Before suspending, this is what lspci gi
Hello,
I'm encountering an issue after resuming my system from suspend to RAM:
my ethernet controller is missing, it seems that the kernel doesn't see
it anymore. It's missing from /sys/class/net.
Before suspending, this is what lspci gives.
03:00.2 Ethernet controller: Realtek Semiconductor Co.
37 matches
Mail list logo
