Re: [PATCH] ACPI / sleep: EC-based wakeup from suspend-to-idle on recent systems

[Tom Lanyon]

Sorry for the slow response - I've just had a chance to run some more tests.

I tried to disable the SD card reader in the BIOS as suggested earlier
in the thread, but that didn't seem to make a significant change.
More inline below.

On Tue, 2017-06-27 at 17:03 +0200, Rafael J. Wysocki wrote:
> I would carry out s2idle under turbostat to see how much PC10
> residency is there while suspended.  That may be a significant factor.
>
> Most likely there is a device preventing the SoC from reaching its
> deepest low-power states under Linux on your system and it needs to be
> identified and dealt with.

I'm not entirely sure how turbostat records metrics so wasn't sure how
to measure correctly.  I kept turbostat running while performing a
s2idle and recorded the output:

https://gist.githubusercontent.com/tomlanyon/3238e742a155e7fa27658aa0960bdee4/raw/98b5f050e5eb2f88af47b2afd17080e7dd85d20f/turbostat

I'm not familiar with the output format - I see some high percentages
of C10, but nothing in Pkg%pc10. Which is of interest in this
scenario?

On 28 June 2017 at 02:14, Srinivas Pandruvada
 wrote:
> Also make sure that you have no FW loading error for i915.
> #dmesg | grep i915
> It will display that Guc FW was loaded etc..
> The latest FW can be downloaded from
> https://01.org/linuxgraphics/downloads/firmware
>
> If you don't see PC10 residency, we can try something more.

I've confirmed that there's no FW errors for the i915.

Re: [PATCH] ACPI / sleep: EC-based wakeup from suspend-to-idle on recent systems

[Tom Lanyon]

Sorry for the slow response - I've just had a chance to run some more tests.

I tried to disable the SD card reader in the BIOS as suggested earlier
in the thread, but that didn't seem to make a significant change.
More inline below.

On Tue, 2017-06-27 at 17:03 +0200, Rafael J. Wysocki wrote:
> I would carry out s2idle under turbostat to see how much PC10
> residency is there while suspended.  That may be a significant factor.
>
> Most likely there is a device preventing the SoC from reaching its
> deepest low-power states under Linux on your system and it needs to be
> identified and dealt with.

I'm not entirely sure how turbostat records metrics so wasn't sure how
to measure correctly.  I kept turbostat running while performing a
s2idle and recorded the output:

https://gist.githubusercontent.com/tomlanyon/3238e742a155e7fa27658aa0960bdee4/raw/98b5f050e5eb2f88af47b2afd17080e7dd85d20f/turbostat

I'm not familiar with the output format - I see some high percentages
of C10, but nothing in Pkg%pc10. Which is of interest in this
scenario?

On 28 June 2017 at 02:14, Srinivas Pandruvada
 wrote:
> Also make sure that you have no FW loading error for i915.
> #dmesg | grep i915
> It will display that Guc FW was loaded etc..
> The latest FW can be downloaded from
> https://01.org/linuxgraphics/downloads/firmware
>
> If you don't see PC10 residency, we can try something more.

I've confirmed that there's no FW errors for the i915.

Re: [PATCH] ACPI / sleep: EC-based wakeup from suspend-to-idle on recent systems

[Tom Lanyon]

On 27 June 2017 at 16:47, Andy Shevchenko  wrote:
> Tom, thanks for this.
> I would speculate that the problem might be in the certain device
> drivers. It would be nice to get statistics which wakeup source
> generates more hits.

Is this something I can determine without CONFIG_ACPI_DEBUG being enabled?

I don't get anything in dmesg other than indications that it's
resuming and then sleeping again every second or so.

[   45.463907] PM: Suspending system (freeze)
[   47.703216] PM: suspend of devices complete after 2028.170 msecs
[   47.721329] PM: late suspend of devices complete after 18.108 msecs
[   47.723153] ACPI : EC: interrupt blocked
[   47.757801] PM: noirq suspend of devices complete after 35.746 msecs
[   47.757802] PM: suspend-to-idle
[   48.944708] Suspended for 0.779 seconds
[   48.945030] ACPI : EC: interrupt unblocked
[   48.980728] PM: noirq resume of devices complete after 35.924 msecs
[   48.982265] ACPI : EC: interrupt blocked
[   49.027946] PM: noirq suspend of devices complete after 47.016 msecs

Re: [PATCH] ACPI / sleep: EC-based wakeup from suspend-to-idle on recent systems

[Tom Lanyon]

On 27 June 2017 at 16:47, Andy Shevchenko  wrote:
> Tom, thanks for this.
> I would speculate that the problem might be in the certain device
> drivers. It would be nice to get statistics which wakeup source
> generates more hits.

Is this something I can determine without CONFIG_ACPI_DEBUG being enabled?

I don't get anything in dmesg other than indications that it's
resuming and then sleeping again every second or so.

[   45.463907] PM: Suspending system (freeze)
[   47.703216] PM: suspend of devices complete after 2028.170 msecs
[   47.721329] PM: late suspend of devices complete after 18.108 msecs
[   47.723153] ACPI : EC: interrupt blocked
[   47.757801] PM: noirq suspend of devices complete after 35.746 msecs
[   47.757802] PM: suspend-to-idle
[   48.944708] Suspended for 0.779 seconds
[   48.945030] ACPI : EC: interrupt unblocked
[   48.980728] PM: noirq resume of devices complete after 35.924 msecs
[   48.982265] ACPI : EC: interrupt blocked
[   49.027946] PM: noirq suspend of devices complete after 47.016 msecs

Re: [PATCH] ACPI / sleep: EC-based wakeup from suspend-to-idle on recent systems

[Tom Lanyon]

On 23 June 2017 at 12:40, Linus Torvalds  wrote:
> On Thu, Jun 22, 2017 at 4:56 PM, Rafael J. Wysocki  wrote:
>>
>> Some recent Dell laptops, including the XPS13 model numbers 9360 and
>> 9365, cannot be woken up from suspend-to-idle by pressing the power
>> button which is unexpected and makes that feature less usable on
>> those systems.  [ details removed ]
>
> This looks much more reasonable and more likely to work on future machines 
> too.
>
> Of course, who knows what broken machines it will cause problems on,
> but it sounds like the code now does what it's supposed to and what
> Win10 does, so maybe it JustWorks(tm). Hah.

Rafael - thanks for your efforts on this.

I wanted to provide some feedback from some quick and naive tests on
an XPS 13 9365 in case it was useful, as it seems like there's still
some way to go before matching Win10's behaviour.

Linux idling w/ screen ON => 17% battery drain per hour.
Linux idling w/ screen OFF => 12% battery drain per hour.
Linux during s2idle => 6% battery drain per hour.
Win10 during sleep => 1% battery drain per hour.

where Linux = 4.12-rc6 + the latest patch from your acpi-pm-test branch.

So whilst s2idle halves the battery drain compared to the machine
staying powered on, it's still significantly more draining than Win10.
Let me know if there's any more useful analysis I can do.

-Tom

Re: [PATCH] ACPI / sleep: EC-based wakeup from suspend-to-idle on recent systems

[Tom Lanyon]

On 23 June 2017 at 12:40, Linus Torvalds  wrote:
> On Thu, Jun 22, 2017 at 4:56 PM, Rafael J. Wysocki  wrote:
>>
>> Some recent Dell laptops, including the XPS13 model numbers 9360 and
>> 9365, cannot be woken up from suspend-to-idle by pressing the power
>> button which is unexpected and makes that feature less usable on
>> those systems.  [ details removed ]
>
> This looks much more reasonable and more likely to work on future machines 
> too.
>
> Of course, who knows what broken machines it will cause problems on,
> but it sounds like the code now does what it's supposed to and what
> Win10 does, so maybe it JustWorks(tm). Hah.

Rafael - thanks for your efforts on this.

I wanted to provide some feedback from some quick and naive tests on
an XPS 13 9365 in case it was useful, as it seems like there's still
some way to go before matching Win10's behaviour.

Linux idling w/ screen ON => 17% battery drain per hour.
Linux idling w/ screen OFF => 12% battery drain per hour.
Linux during s2idle => 6% battery drain per hour.
Win10 during sleep => 1% battery drain per hour.

where Linux = 4.12-rc6 + the latest patch from your acpi-pm-test branch.

So whilst s2idle halves the battery drain compared to the machine
staying powered on, it's still significantly more draining than Win10.
Let me know if there's any more useful analysis I can do.

-Tom

Re: [PATCH 0/3] ACPI / sleep: Support power button wakeup from S2I on recent Dell laptops

[Tom Lanyon]

On 2 June 2017 at 00:59, Rafael J. Wysocki  wrote:
>
> Quoting from my cover letter:
>
> "After this series there still is a concern regarding the possible increase of
> power draw that may result from the processing of non-wakeup EC events while
> suspended which is why the change only affects Dell XPS13 9360 and 9365
> for now."
>
> So that is what happens, unfortunately, and we can't do much about it
> at the moment.

OK, but at the moment this is a regression in functionality on those
platforms. Without this patchset, I can successfully s2idle
suspend/resume on an XPS 9365 (albeit with a little bit of awkward
fiddling of the power button to resume). After the patchset, I can't
realistically go into s2idle at all.

> The only way to avoid that would be to reconfigure the EC during
> suspend to stop generating non-wakeup events, but today we have no
> reliable way to do that.

I thought I had read one one of the threads that this was possible in
the same way that it is for Windows on these laptops.  What's missing
to make this possible?

Tom

Re: [PATCH 0/3] ACPI / sleep: Support power button wakeup from S2I on recent Dell laptops

[Tom Lanyon]

On 2 June 2017 at 00:59, Rafael J. Wysocki  wrote:
>
> Quoting from my cover letter:
>
> "After this series there still is a concern regarding the possible increase of
> power draw that may result from the processing of non-wakeup EC events while
> suspended which is why the change only affects Dell XPS13 9360 and 9365
> for now."
>
> So that is what happens, unfortunately, and we can't do much about it
> at the moment.

OK, but at the moment this is a regression in functionality on those
platforms. Without this patchset, I can successfully s2idle
suspend/resume on an XPS 9365 (albeit with a little bit of awkward
fiddling of the power button to resume). After the patchset, I can't
realistically go into s2idle at all.

> The only way to avoid that would be to reconfigure the EC during
> suspend to stop generating non-wakeup events, but today we have no
> reliable way to do that.

I thought I had read one one of the threads that this was possible in
the same way that it is for Windows on these laptops.  What's missing
to make this possible?

Tom

Re: [PATCH 0/3] ACPI / sleep: Support power button wakeup from S2I on recent Dell laptops

[Tom Lanyon]

[resend as text/plain]

On Thu, 2017-06-01 at 01:23 +0200, Rafael J. Wysocki wrote:
> Hi All,
>
> This is a follow-up for a patch series posted some time ago:
>
> http://marc.info/?l=linux-kernel=149324246701378=2

I've applied Rafael's s2idle-dell-test branch to 4.12.0-rc3 and tested
on a Dell 9365 and, whilst it's significantly improved, it's not yet
working correctly.

Previously I could suspend (s2idle and deep), but it took an awkward
~8 second press of the power button to get it to resume, and I could
never get resume to work when triggering suspend/resume via close/open
of the lid.

With this patchset applied, I can suspend (s2idle) and a momentary
press of the power button resumes successfully.  I can also use the
lid switch to both suspend and resume successfully.

However, the EC events appear to trigger the machine to wake very
frequently whilst it's supposed to be suspended. This is visible via
the kernel messages at the end of this mail (leaving it in a suspended
state for a few hours resulted in many thousands of these messages),
and the high power draw witnessed.

Let me know if there's anything I can do to help debug further.

Tom

[   43.669798] PM: Syncing filesystems ... done.
[   43.675412] PM: Preparing system for sleep (freeze)
[   43.695469] Freezing user space processes ... (elapsed 0.001 seconds) done.
[   43.696769] OOM killer disabled.
[   43.696770] Freezing remaining freezable tasks ... (elapsed 0.001
seconds) done.
[   43.697914] PM: Suspending system (freeze)
[   43.910325] wlan0: deauthenticating from 9c:1c:12:c7:c2:f1 by local
choice (Reason: 3=DEAUTH_LEAVING)
[   44.112944] psmouse serio1: Failed to disable mouse on isa0060/serio1
[   45.721790] PM: suspend of devices complete after 1811.701 msecs
[   45.739769] PM: late suspend of devices complete after 17.956 msecs
[   45.742599] ACPI : EC: interrupt blocked
[   45.744774] xhci_hcd :00:14.0: System wakeup enabled by ACPI
[   45.776254] PM: noirq suspend of devices complete after 34.702 msecs
[   45.776256] PM: suspend-to-idle
[   47.029237] Suspended for 0.327 seconds
[   47.029335] PM: resume from suspend-to-idle
[   47.029587] ACPI : EC: interrupt unblocked
[   47.064470] xhci_hcd :00:14.0: System wakeup disabled by ACPI
[   47.065268] PM: noirq resume of devices complete after 35.894 msecs
[   47.066264] ACPI : EC: interrupt blocked
[   47.079210] xhci_hcd :00:14.0: System wakeup enabled by ACPI
[   47.112461] PM: noirq suspend of devices complete after 47.019 msecs
[   47.112538] ACPI : EC: interrupt unblocked
[   47.147672] xhci_hcd :00:14.0: System wakeup disabled by ACPI
[   47.148516] PM: noirq resume of devices complete after 36.051 msecs
[   47.149610] ACPI : EC: interrupt blocked
[   47.161002] xhci_hcd :00:14.0: System wakeup enabled by ACPI
[   47.192546] PM: noirq suspend of devices complete after 43.955 msecs
[   47.192551] PM: suspend-to-idle
[   48.374756] Suspended for 1.836 seconds
[   48.374870] PM: resume from suspend-to-idle
[   48.375284] ACPI : EC: interrupt unblocked

Re: [PATCH 0/3] ACPI / sleep: Support power button wakeup from S2I on recent Dell laptops

[Tom Lanyon]

[resend as text/plain]

On Thu, 2017-06-01 at 01:23 +0200, Rafael J. Wysocki wrote:
> Hi All,
>
> This is a follow-up for a patch series posted some time ago:
>
> http://marc.info/?l=linux-kernel=149324246701378=2

I've applied Rafael's s2idle-dell-test branch to 4.12.0-rc3 and tested
on a Dell 9365 and, whilst it's significantly improved, it's not yet
working correctly.

Previously I could suspend (s2idle and deep), but it took an awkward
~8 second press of the power button to get it to resume, and I could
never get resume to work when triggering suspend/resume via close/open
of the lid.

With this patchset applied, I can suspend (s2idle) and a momentary
press of the power button resumes successfully.  I can also use the
lid switch to both suspend and resume successfully.

However, the EC events appear to trigger the machine to wake very
frequently whilst it's supposed to be suspended. This is visible via
the kernel messages at the end of this mail (leaving it in a suspended
state for a few hours resulted in many thousands of these messages),
and the high power draw witnessed.

Let me know if there's anything I can do to help debug further.

Tom

[   43.669798] PM: Syncing filesystems ... done.
[   43.675412] PM: Preparing system for sleep (freeze)
[   43.695469] Freezing user space processes ... (elapsed 0.001 seconds) done.
[   43.696769] OOM killer disabled.
[   43.696770] Freezing remaining freezable tasks ... (elapsed 0.001
seconds) done.
[   43.697914] PM: Suspending system (freeze)
[   43.910325] wlan0: deauthenticating from 9c:1c:12:c7:c2:f1 by local
choice (Reason: 3=DEAUTH_LEAVING)
[   44.112944] psmouse serio1: Failed to disable mouse on isa0060/serio1
[   45.721790] PM: suspend of devices complete after 1811.701 msecs
[   45.739769] PM: late suspend of devices complete after 17.956 msecs
[   45.742599] ACPI : EC: interrupt blocked
[   45.744774] xhci_hcd :00:14.0: System wakeup enabled by ACPI
[   45.776254] PM: noirq suspend of devices complete after 34.702 msecs
[   45.776256] PM: suspend-to-idle
[   47.029237] Suspended for 0.327 seconds
[   47.029335] PM: resume from suspend-to-idle
[   47.029587] ACPI : EC: interrupt unblocked
[   47.064470] xhci_hcd :00:14.0: System wakeup disabled by ACPI
[   47.065268] PM: noirq resume of devices complete after 35.894 msecs
[   47.066264] ACPI : EC: interrupt blocked
[   47.079210] xhci_hcd :00:14.0: System wakeup enabled by ACPI
[   47.112461] PM: noirq suspend of devices complete after 47.019 msecs
[   47.112538] ACPI : EC: interrupt unblocked
[   47.147672] xhci_hcd :00:14.0: System wakeup disabled by ACPI
[   47.148516] PM: noirq resume of devices complete after 36.051 msecs
[   47.149610] ACPI : EC: interrupt blocked
[   47.161002] xhci_hcd :00:14.0: System wakeup enabled by ACPI
[   47.192546] PM: noirq suspend of devices complete after 43.955 msecs
[   47.192551] PM: suspend-to-idle
[   48.374756] Suspended for 1.836 seconds
[   48.374870] PM: resume from suspend-to-idle
[   48.375284] ACPI : EC: interrupt unblocked

Failure with SATA DVD-RW

[Tom Lanyon]

Hi list,

Just built a new machine with a Pioneer SATA DVD drive and linux
distro install CDs are not recognising it. The drive is connected to
the ICH9R southbridge of an Intel P35 chipset motherboard.

I can boot from the CD/DVD so the drive itself is working, but the
kernel reports the following:

scsi4: ahci
ata5: SATA link up at 1.5 Gbps (SStatus 113 SControl 300)
ata5.00: ATAPI, max UDMA/66
ata5.00: qc timeout (cmd 0xef)
ata5.00: failed to set xfermode (err_mask=0x104)
ata5.00: limiting speed to UDMA/44
ata5: failed to recover some devices, retrying in 5 secs
ata5: port is slow to respond, please be patient (Status 0x80)
ata5: port failed to respond (30 secs, status 0x80)
ata5: COMRESET failed (device not ready)
ata5: hardreset failed, retrying in 5 secs
ata5: SATA link up at 1.5 Gbps (SStatus 113 SControl 300)
ata5.00: ATAPI, max UDMA/66
ata5.00: qc timeout (cmd 0xef)
ata5.00: failed to set xfermode (err_mask=0x104)
ata5.00: limiting speed to PIO0
ata5: failed to recover some devices, retrying in 5 secs
ata5: port is slow to respond, please be patient (Status 0x80)
ata5: port failed to respond (30 secs, status 0x80)
ata5: COMRESET failed (device not ready)
ata5: hardreset failed, retrying in 5 secs
ata5.00: ATAPI, max UDMA/66
ata5.00: qc timeout (cmd 0xef)
ata5.00: failed to set xfermode (err_mask=0x104)
ata5.00: disabled

This is 2.6.19 (probably with a few distribution patches) on an
install CD. I also tried setting the SATA controller to a 'compatible
IDE' mode and the hard drives and DVD drive are detected and work
properly.

Any ideas what to try to get it working under AHCI?

-- 
Tom Lanyon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Failure with SATA DVD-RW

[Tom Lanyon]

Hi list,

Just built a new machine with a Pioneer SATA DVD drive and linux
distro install CDs are not recognising it. The drive is connected to
the ICH9R southbridge of an Intel P35 chipset motherboard.

I can boot from the CD/DVD so the drive itself is working, but the
kernel reports the following:

scsi4: ahci
ata5: SATA link up at 1.5 Gbps (SStatus 113 SControl 300)
ata5.00: ATAPI, max UDMA/66
ata5.00: qc timeout (cmd 0xef)
ata5.00: failed to set xfermode (err_mask=0x104)
ata5.00: limiting speed to UDMA/44
ata5: failed to recover some devices, retrying in 5 secs
ata5: port is slow to respond, please be patient (Status 0x80)
ata5: port failed to respond (30 secs, status 0x80)
ata5: COMRESET failed (device not ready)
ata5: hardreset failed, retrying in 5 secs
ata5: SATA link up at 1.5 Gbps (SStatus 113 SControl 300)
ata5.00: ATAPI, max UDMA/66
ata5.00: qc timeout (cmd 0xef)
ata5.00: failed to set xfermode (err_mask=0x104)
ata5.00: limiting speed to PIO0
ata5: failed to recover some devices, retrying in 5 secs
ata5: port is slow to respond, please be patient (Status 0x80)
ata5: port failed to respond (30 secs, status 0x80)
ata5: COMRESET failed (device not ready)
ata5: hardreset failed, retrying in 5 secs
ata5.00: ATAPI, max UDMA/66
ata5.00: qc timeout (cmd 0xef)
ata5.00: failed to set xfermode (err_mask=0x104)
ata5.00: disabled

This is 2.6.19 (probably with a few distribution patches) on an
install CD. I also tried setting the SATA controller to a 'compatible
IDE' mode and the hard drives and DVD drive are detected and work
properly.

Any ideas what to try to get it working under AHCI?

-- 
Tom Lanyon
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: runaway loop modprobe binfmt-0000

[Tom Lanyon]

On 1/6/07, Andrew Morton <[EMAIL PROTECTED]> wrote:

On Sat, 6 Jan 2007 09:43:14 +1030
"Tom Lanyon" <[EMAIL PROTECTED]> wrote:

> How can I discover
> what is trying to load binfmt- and why is it looping?

Start with this, I guess..

--- a/kernel/kmod.c~a
+++ a/kernel/kmod.c
@@ -98,10 +98,12 @@ int request_module(const char *fmt, ...)
atomic_inc(_concurrent);
if (atomic_read(_concurrent) > max_modprobes) {
/* We may be blaming an innocent here, but unlikely */
-   if (kmod_loop_msg++ < 5)
+   if (kmod_loop_msg++ < 5) {
printk(KERN_ERR
   "request_module: runaway loop modprobe %s\n",
   module_name);
+   dump_stack();
+   }
atomic_dec(_concurrent);
return -ENOMEM;
}
_




Thanks for the reply, Andrew.

How interesting... added that to kmod.c, rebuilt without change to
config, reboot machine booted perfectly!

I'm going to leave it for now, but I'll leave the dump_stack() call in
there in case further issues arise.

Regards

--
Tom Lanyon
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: runaway loop modprobe binfmt-0000

[Tom Lanyon]

On 1/6/07, Andrew Morton [EMAIL PROTECTED] wrote:

On Sat, 6 Jan 2007 09:43:14 +1030
Tom Lanyon [EMAIL PROTECTED] wrote:

 How can I discover
 what is trying to load binfmt- and why is it looping?

Start with this, I guess..

--- a/kernel/kmod.c~a
+++ a/kernel/kmod.c
@@ -98,10 +98,12 @@ int request_module(const char *fmt, ...)
atomic_inc(kmod_concurrent);
if (atomic_read(kmod_concurrent)  max_modprobes) {
/* We may be blaming an innocent here, but unlikely */
-   if (kmod_loop_msg++  5)
+   if (kmod_loop_msg++  5) {
printk(KERN_ERR
   request_module: runaway loop modprobe %s\n,
   module_name);
+   dump_stack();
+   }
atomic_dec(kmod_concurrent);
return -ENOMEM;
}
_




Thanks for the reply, Andrew.

How interesting... added that to kmod.c, rebuilt without change to
config, reboot machine booted perfectly!

I'm going to leave it for now, but I'll leave the dump_stack() call in
there in case further issues arise.

Regards

--
Tom Lanyon
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)

[Tom Lanyon]

On 1/7/07, Tom Lanyon <[EMAIL PROTECTED]> wrote:

I've been following this thread for a while now as I started
experiencing file corruption in rtorrent when I upgraded to 2.6.19. I
am using reiserfs.


However, moving to 2.6.20-rc3 does indeed seem to fix the issue thus far...

--
Tom Lanyon
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)

[Tom Lanyon]

On 12/27/06, Linus Torvalds <[EMAIL PROTECTED]> wrote:

What would also actually be interesting is whether somebody can reproduce
this on Reiserfs, for example. I _think_ all the reports I've seen are on
ext2 or ext3, and if this is somehow writeback-related, it could be some
bug that is just shared between the two by virtue of them still having a
lot of stuff in common.

Linus


I've been following this thread for a while now as I started
experiencing file corruption in rtorrent when I upgraded to 2.6.19. I
am using reiserfs.

--
Tom Lanyon
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)

[Tom Lanyon]

On 12/27/06, Linus Torvalds [EMAIL PROTECTED] wrote:

What would also actually be interesting is whether somebody can reproduce
this on Reiserfs, for example. I _think_ all the reports I've seen are on
ext2 or ext3, and if this is somehow writeback-related, it could be some
bug that is just shared between the two by virtue of them still having a
lot of stuff in common.

Linus


I've been following this thread for a while now as I started
experiencing file corruption in rtorrent when I upgraded to 2.6.19. I
am using reiserfs.

--
Tom Lanyon
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)

[Tom Lanyon]

On 1/7/07, Tom Lanyon [EMAIL PROTECTED] wrote:

I've been following this thread for a while now as I started
experiencing file corruption in rtorrent when I upgraded to 2.6.19. I
am using reiserfs.


However, moving to 2.6.20-rc3 does indeed seem to fix the issue thus far...

--
Tom Lanyon
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

runaway loop modprobe binfmt-0000

[Tom Lanyon]

Greetings,

I'm encountering a rather annoying error on one of our AMD Opteron
boxes. I recompiled the working 2.6.17 kernel to add some extra SCSI
support and booted to find something similar to:

usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
PNP: PS/2 Controller [PNP0303:KBD,PNP0f0e:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
device-mapper: ioctl: 4.10.0-ioctl (2006-09-14) initialised: [EMAIL PROTECTED]
device-mapper: multipath: version 1.0.5 loaded
device-mapper: multipath round-robin: version 1.0.0 loaded
device-mapper: multipath emc: version 0.0.3 loaded
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Freeing unused kernel memory: 324k freed
request_module: runaway loop modprobe binfmt-
request_module: runaway loop modprobe binfmt-
request_module: runaway loop modprobe binfmt-
request_module: runaway loop modprobe binfmt-
request_module: runaway loop modprobe binfmt-

... and then a hung kernel.

I figured I'd enabled/disabled something I shouldn't have and went
through the kernel config many times, recompiling with different
options (including ELF and misc emulation support), but to no avail.

As time ticked closer to 5pm on a Friday my interest decreased and so
I tried upgrading to 2.6.18 and then 2.6.19, with a tonne of different
configurations. Still nothing. The best I could achieve was on a fresh
2.6.19.1 I managed to pass the modprobe and load some input drivers,
but then it hung directly after that.

...
request_module: runaway loop modprobe binfmt-
request_module: runaway loop modprobe binfmt-
request_module: runaway loop modprobe binfmt-
input: AT Translated Set 2 keyboard as /class/input/input0
input: PS/2 Generic Mouse as /class/input/input1


Any advice on debugging this would be appreciated. How can I discover
what is trying to load binfmt- and why is it looping?

Regards

--
Tom Lanyon
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

runaway loop modprobe binfmt-0000

[Tom Lanyon]

Greetings,

I'm encountering a rather annoying error on one of our AMD Opteron
boxes. I recompiled the working 2.6.17 kernel to add some extra SCSI
support and booted to find something similar to:

usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
PNP: PS/2 Controller [PNP0303:KBD,PNP0f0e:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
device-mapper: ioctl: 4.10.0-ioctl (2006-09-14) initialised: [EMAIL PROTECTED]
device-mapper: multipath: version 1.0.5 loaded
device-mapper: multipath round-robin: version 1.0.0 loaded
device-mapper: multipath emc: version 0.0.3 loaded
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Freeing unused kernel memory: 324k freed
request_module: runaway loop modprobe binfmt-
request_module: runaway loop modprobe binfmt-
request_module: runaway loop modprobe binfmt-
request_module: runaway loop modprobe binfmt-
request_module: runaway loop modprobe binfmt-

... and then a hung kernel.

I figured I'd enabled/disabled something I shouldn't have and went
through the kernel config many times, recompiling with different
options (including ELF and misc emulation support), but to no avail.

As time ticked closer to 5pm on a Friday my interest decreased and so
I tried upgrading to 2.6.18 and then 2.6.19, with a tonne of different
configurations. Still nothing. The best I could achieve was on a fresh
2.6.19.1 I managed to pass the modprobe and load some input drivers,
but then it hung directly after that.

...
request_module: runaway loop modprobe binfmt-
request_module: runaway loop modprobe binfmt-
request_module: runaway loop modprobe binfmt-
input: AT Translated Set 2 keyboard as /class/input/input0
input: PS/2 Generic Mouse as /class/input/input1


Any advice on debugging this would be appreciated. How can I discover
what is trying to load binfmt- and why is it looping?

Regards

--
Tom Lanyon
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/