On Sat, 2014-08-16 at 02:46 +0200, Rafael J. Wysocki wrote:
> On Friday, August 15, 2014 10:17:42 AM Markus Gutschke wrote:
> > Just wondering if any of you had any other ideas of what I could try
> > to help debug this problem?
>
> My theory is that there is a device in your system that we don't
On Sat, 2014-08-16 at 02:46 +0200, Rafael J. Wysocki wrote:
On Friday, August 15, 2014 10:17:42 AM Markus Gutschke wrote:
Just wondering if any of you had any other ideas of what I could try
to help debug this problem?
My theory is that there is a device in your system that we don't have a
I collected all the data that you asked for and attached it to the
bug: https://bugzilla.kernel.org/show_bug.cgi?id=80911
Yes, both acpidump output and the list of PNP devices changes when I
update the kernel. I was hoping to give you a brief "diff" output for
the changes; but there are too many
I collected all the data that you asked for and attached it to the
bug: https://bugzilla.kernel.org/show_bug.cgi?id=80911
Yes, both acpidump output and the list of PNP devices changes when I
update the kernel. I was hoping to give you a brief diff output for
the changes; but there are too many
On Friday, August 15, 2014 10:17:42 AM Markus Gutschke wrote:
> Just wondering if any of you had any other ideas of what I could try
> to help debug this problem?
My theory is that there is a device in your system that we don't have a driver
for, but it had been enumerated as a PNP device before
Just wondering if any of you had any other ideas of what I could try
to help debug this problem?
Thanks,
Markus
On Tue, Aug 12, 2014 at 9:11 AM, Markus Gutschke wrote:
> As I said earlier in this thread, echo'ing "devices" into "pm_test"
> does not result in a crash; but doing so for
Just wondering if any of you had any other ideas of what I could try
to help debug this problem?
Thanks,
Markus
On Tue, Aug 12, 2014 at 9:11 AM, Markus Gutschke mar...@gutschke.com wrote:
As I said earlier in this thread, echo'ing devices into pm_test
does not result in a crash; but doing so
On Friday, August 15, 2014 10:17:42 AM Markus Gutschke wrote:
Just wondering if any of you had any other ideas of what I could try
to help debug this problem?
My theory is that there is a device in your system that we don't have a driver
for, but it had been enumerated as a PNP device before
As I said earlier in this thread, echo'ing "devices" into "pm_test"
does not result in a crash; but doing so for "platform" does.
Markus
On Aug 12, 2014 1:26 AM, "Zhang Rui" wrote:
>
> On Sat, 2014-08-09 at 03:14 -0700, Markus Gutschke wrote:
> > I am back and have physical access to the
On Sat, 2014-08-09 at 03:14 -0700, Markus Gutschke wrote:
> I am back and have physical access to the machine now.
>
great!
> I re-ran the test just to be sure, and I can confirm that "platform"
> does in fact result in a crash.
>
what about "devices"?
I mean
# echo devices >
On Sat, 2014-08-09 at 03:14 -0700, Markus Gutschke wrote:
I am back and have physical access to the machine now.
great!
I re-ran the test just to be sure, and I can confirm that platform
does in fact result in a crash.
what about devices?
I mean
# echo devices /sys/power/pm_test
and see
As I said earlier in this thread, echo'ing devices into pm_test
does not result in a crash; but doing so for platform does.
Markus
On Aug 12, 2014 1:26 AM, Zhang Rui rui.zh...@intel.com wrote:
On Sat, 2014-08-09 at 03:14 -0700, Markus Gutschke wrote:
I am back and have physical access to the
I am back and have physical access to the machine now.
I re-ran the test just to be sure, and I can confirm that "platform"
does in fact result in a crash.
Furthermore, I ran the test that Rui asked for. I suspended, resumed,
and upon crashing power-cycled the machine ASAP. "dmesg" suggests that
I am back and have physical access to the machine now.
I re-ran the test just to be sure, and I can confirm that platform
does in fact result in a crash.
Furthermore, I ran the test that Rui asked for. I suspended, resumed,
and upon crashing power-cycled the machine ASAP. dmesg suggests that
the
"platform" does in fact appear to cause a crash (at least, I can't
reach the machine anymore, after having suspended).
I am still on the road and have to do this remotely, and I cannot get
hold of my helper right now. I'll try again later tonight or maybe the
next day(s) and will get back to you
On Wednesday, August 06, 2014 11:31:07 AM Markus Gutschke wrote:
> I tried removing snd_hda_intel, but it didn't make any difference.
>
> I then followed your instructions to turn on tracing, but I am more
> puzzled than I was before. The crash reliably happens, every time I
> suspend/resume
I tried removing snd_hda_intel, but it didn't make any difference.
I then followed your instructions to turn on tracing, but I am more
puzzled than I was before. The crash reliably happens, every time I
suspend/resume without first having tracing turned on. But as soon as
I enter "echo devices
I tried removing snd_hda_intel, but it didn't make any difference.
I then followed your instructions to turn on tracing, but I am more
puzzled than I was before. The crash reliably happens, every time I
suspend/resume without first having tracing turned on. But as soon as
I enter echo devices
On Wednesday, August 06, 2014 11:31:07 AM Markus Gutschke wrote:
I tried removing snd_hda_intel, but it didn't make any difference.
I then followed your instructions to turn on tracing, but I am more
puzzled than I was before. The crash reliably happens, every time I
suspend/resume without
platform does in fact appear to cause a crash (at least, I can't
reach the machine anymore, after having suspended).
I am still on the road and have to do this remotely, and I cannot get
hold of my helper right now. I'll try again later tonight or maybe the
next day(s) and will get back to you
Hi, Markus,
On Mon, 2014-08-04 at 09:06 -0700, Markus Gutschke wrote:
> Thanks for checking in. And no, I have not heard from Zhang since my
> last e-mail. I suspect he is still working on finding a solution.
Yes, I was trying to find out what differences commit
On Monday, August 04, 2014 09:06:52 AM Markus Gutschke wrote:
> Thanks for checking in. And no, I have not heard from Zhang since my
> last e-mail. I suspect he is still working on finding a solution. But
> you are of course right, reverting the patch in the meantime might be
> a good idea.
It
Thanks for checking in. And no, I have not heard from Zhang since my
last e-mail. I suspect he is still working on finding a solution. But
you are of course right, reverting the patch in the meantime might be
a good idea. I would love to be able to suspend my laptop again. But I
defer to Zhang for
On Sat 2014-07-26 08:52:34, Markus Gutschke wrote:
> Sorry for the delay. Remotely debugging kernels over a shared and
> flaky 1MBps terrestrial wireless connection is quite a new experience
> to me.
>
> In any case, I was able to collect all the data that you asked for. I
> then used
On Sat 2014-07-26 08:52:34, Markus Gutschke wrote:
Sorry for the delay. Remotely debugging kernels over a shared and
flaky 1MBps terrestrial wireless connection is quite a new experience
to me.
In any case, I was able to collect all the data that you asked for. I
then used pm-suspend to put
Thanks for checking in. And no, I have not heard from Zhang since my
last e-mail. I suspect he is still working on finding a solution. But
you are of course right, reverting the patch in the meantime might be
a good idea. I would love to be able to suspend my laptop again. But I
defer to Zhang for
On Monday, August 04, 2014 09:06:52 AM Markus Gutschke wrote:
Thanks for checking in. And no, I have not heard from Zhang since my
last e-mail. I suspect he is still working on finding a solution. But
you are of course right, reverting the patch in the meantime might be
a good idea.
It has
Hi, Markus,
On Mon, 2014-08-04 at 09:06 -0700, Markus Gutschke wrote:
Thanks for checking in. And no, I have not heard from Zhang since my
last e-mail. I suspect he is still working on finding a solution.
Yes, I was trying to find out what differences commit
Sorry for the delay. Remotely debugging kernels over a shared and
flaky 1MBps terrestrial wireless connection is quite a new experience
to me.
In any case, I was able to collect all the data that you asked for. I
then used "pm-suspend" to put the machine to sleep and asked a helper
to physically
Sorry for the delay. Remotely debugging kernels over a shared and
flaky 1MBps terrestrial wireless connection is quite a new experience
to me.
In any case, I was able to collect all the data that you asked for. I
then used pm-suspend to put the machine to sleep and asked a helper
to physically
On Thu, 2014-07-17 at 10:27 -0700, Markus Gutschke wrote:
> Please note the crash in "dmesg" right after booting. This looks relevant:
>
I think the crash log also exists in 3.15 kernel, can you please verify
this?
> https://medusa.gutschke.com/markus/acpi/after-dmesg.txt
>
On Thu, 2014-07-17 at 10:27 -0700, Markus Gutschke wrote:
Please note the crash in dmesg right after booting. This looks relevant:
I think the crash log also exists in 3.15 kernel, can you please verify
this?
https://medusa.gutschke.com/markus/acpi/after-dmesg.txt
Please note the crash in "dmesg" right after booting. This looks relevant:
https://medusa.gutschke.com/markus/acpi/after-dmesg.txt
https://medusa.gutschke.com/markus/acpi/acpidump.txt
https://medusa.gutschke.com/markus/acpi/before-platform-devices-firmware-node.txt
Hi, Markus,
Can you please attach
1. the acpidump output
2. dmesg output after boot in 3.16-rc
3. the output of
a) "grep . /sys/bus/pnp/devices/*/firmware_node/*"
b) "grep . /sys/bus/pnp/devices/*/*"
c) "grep . /sys/bus/platform/devices/*/firmware_node/*"
d) "grep .
Adding the reviewers of the faulty change list to the cc list for this
e-mail. I hope that is considered proper etiquette for the LKML.
On Tue, Jul 15, 2014 at 6:51 PM, Markus Gutschke wrote:
> My Dell M4400 has been pretty well-supported by Linux a couple of
> years now, but recent 3.16-rcX
Adding the reviewers of the faulty change list to the cc list for this
e-mail. I hope that is considered proper etiquette for the LKML.
On Tue, Jul 15, 2014 at 6:51 PM, Markus Gutschke mar...@gutschke.com wrote:
My Dell M4400 has been pretty well-supported by Linux a couple of
years now, but
Hi, Markus,
Can you please attach
1. the acpidump output
2. dmesg output after boot in 3.16-rc
3. the output of
a) grep . /sys/bus/pnp/devices/*/firmware_node/*
b) grep . /sys/bus/pnp/devices/*/*
c) grep . /sys/bus/platform/devices/*/firmware_node/*
d) grep .
Please note the crash in dmesg right after booting. This looks relevant:
https://medusa.gutschke.com/markus/acpi/after-dmesg.txt
https://medusa.gutschke.com/markus/acpi/acpidump.txt
https://medusa.gutschke.com/markus/acpi/before-platform-devices-firmware-node.txt
My Dell M4400 has been pretty well-supported by Linux a couple of
years now, but recent 3.16-rcX cause hard crashes when resuming from
Suspend-to-RAM.
This is tricky to debug, as device drivers are not yet restored by the
time that the crash happens. So, I can't use Page-UP to scroll the
screen
My Dell M4400 has been pretty well-supported by Linux a couple of
years now, but recent 3.16-rcX cause hard crashes when resuming from
Suspend-to-RAM.
This is tricky to debug, as device drivers are not yet restored by the
time that the crash happens. So, I can't use Page-UP to scroll the
screen
40 matches
Mail list logo
