and I hope it is sufficiently complete
for you to make progress in debugging why my machine is unhappy.
Please don't hesitate to ask, if you think I can provide other data
and/or run other tests.
Markus
On Fri, Aug 15, 2014 at 5:46 PM, Rafael J. Wysocki wrote:
> On Friday, August 15, 2014 10:17:42 AM Ma
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 the change that
triggered
the problem
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 resul
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
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
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
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
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
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
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
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 the machine
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
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
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.
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
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
I have done some more testing, and it now looks as if this was actually
a hardware fault. Reseating the PCI-E card made the problem go away
(knock on wood). I am a little puzzled that it is possible for the card
to show up on the PCI bus, and for the driver to be able to detect
whether a disk
I have done some more testing, and it now looks as if this was actually
a hardware fault. Reseating the PCI-E card made the problem go away
(knock on wood). I am a little puzzled that it is possible for the card
to show up on the PCI bus, and for the driver to be able to detect
whether a disk
I just tried hooking up a Hitachi 1TB SATA-II drive to a Marvell 7042
based controller, and the most recent Linux kernel (2.6.23-rc1) fails to
properly initialize the interface. Here are the relevant kernel messages:
kernel: [43.312417] sata_mv :06:00.0: version 0.81
kernel: [43.312752]
I just tried hooking up a Hitachi 1TB SATA-II drive to a Marvell 7042
based controller, and the most recent Linux kernel (2.6.23-rc1) fails to
properly initialize the interface. Here are the relevant kernel messages:
kernel: [43.312417] sata_mv :06:00.0: version 0.81
kernel: [43.312752]
Kawai, Hidehiro wrote:
Requirements are:
(1) a user can change the core dump settings _anytime_
- sometimes want to dump anonymous shared memory segments and
sometimes don't want to dump them
I might not have been sufficiently clear about this in my previous
e-mail. Currently,
Kawai, Hidehiro wrote:
Requirements are:
(1) a user can change the core dump settings _anytime_
- sometimes want to dump anonymous shared memory segments and
sometimes don't want to dump them
I might not have been sufficiently clear about this in my previous
e-mail. Currently,
David Howells wrote:
How does it work when you can't actually get back to userspace to have
userspace do the coredump? You still have to handle the userspace equivalents
of double/triple faults.
My experience shows that there are only very rare occurrences of
situations where you cannot get
David Howells wrote:
How does it work when you can't actually get back to userspace to have
userspace do the coredump? You still have to handle the userspace equivalents
of double/triple faults.
My experience shows that there are only very rare occurrences of
situations where you cannot get
Kawai, Hidehiro wrote:
This patch series is version 3 of the core dump masking feature,
which provides a per-process flag not to dump anonymous shared
memory segments.
I just wanted to remind you that you need to be careful about dumping
the [vdso] segment no matter whether you omit other
Kawai, Hidehiro wrote:
This patch series is version 3 of the core dump masking feature,
which provides a per-process flag not to dump anonymous shared
memory segments.
I just wanted to remind you that you need to be careful about dumping
the [vdso] segment no matter whether you omit other
lems with vi
whatsoever. Of course, this only works on the console, but for my
terminal windows, I can set these values in resource or configuration
files. So, all of this is a user-space problem. No need to complicate
the kernel code.
Markus
--
Markus Gutschke
33 matches
Mail list logo
