On Fri 2019-04-26 07:58:49, Bart Van Assche wrote:
> On Fri, 2019-04-26 at 12:32 +0200, Pavel Machek wrote:
> > [detached HEAD 916db0d] Revert "scsi: sd: Inline sd_probe_part2()"
> > 1 file changed, 58 insertions(+), 43 deletions(-)
> > pavel@duo:/data/l/linux-next-32$ git revert
> >
On Fri, 2019-04-26 at 12:32 +0200, Pavel Machek wrote:
> [detached HEAD 916db0d] Revert "scsi: sd: Inline sd_probe_part2()"
> 1 file changed, 58 insertions(+), 43 deletions(-)
> pavel@duo:/data/l/linux-next-32$ git revert
> 21e6ba3f0e0257cce1a226c1f15e0a8ba4338ca3
> Editing file:
r way to analyze what is
> >> going on. I had not expected that these patches would cause any suspend/
> >> resume problems.
> >
> > Not even d16ece reverts:
> >
> > pavel@duo:/data/l/linux-next-32$ git show | head -3
> > commit 76c938fcaa4b
he following:
>>
>> git revert d16ece577bf2cee7f94bab75a0d967bcb89dd2a7 &&
>> git revert 21e6ba3f0e0257cce1a226c1f15e0a8ba4338ca3
>>
>> I will see whether I can come up with a better way to analyze what is
>> going on. I had not expected that these patches would cause any suspend
2a7 &&
> git revert 21e6ba3f0e0257cce1a226c1f15e0a8ba4338ca3
>
> I will see whether I can come up with a better way to analyze what is
> going on. I had not expected that these patches would cause any suspend/
> resume problems.
Not even d16ece reverts:
pavel@duo:/data
On Wed, 2019-04-24 at 12:17 +0200, Pavel Machek wrote:
> On Tue 2019-04-23 07:09:42, Bart Van Assche wrote:
> > On 4/23/19 3:22 AM, Pavel Machek wrote:
> > > > > It boots ok (unlike mainline -- I'm debugging that), and I can suspend
> > > > > and resume... but then cursor in X is moving and I can
can come up with a better way to analyze what is
going on. I had not expected that these patches would cause any suspend/
resume problems.
Bart.
On Wed 2019-04-24 22:48:32, Pavel Machek wrote:
> Hi!
>
> > Not block, but it seems scsi subsystem is:
>
> commit 21e6ba3f0e0257cce1a226c1f15e0a8ba4338ca3
> Author: Bart Van Assche
> Date: Wed Mar 20 13:09:19 2019 -0700
>
> scsi: sd: Rely on the driver core for asynchronous probing
>
>
Hi!
> Not block, but it seems scsi subsystem is:
commit 21e6ba3f0e0257cce1a226c1f15e0a8ba4338ca3
Author: Bart Van Assche
Date: Wed Mar 20 13:09:19 2019 -0700
scsi: sd: Rely on the driver core for asynchronous probing
As explained during the 2018 LSF/MM session about increasing SCSI
On Wed 2019-04-24 12:48:50, Pavel Machek wrote:
> On Wed 2019-04-24 11:54:31, Pavel Machek wrote:
> > On Tue 2019-04-23 07:55:05, Jens Axboe wrote:
> > > On 4/23/19 4:22 AM, Pavel Machek wrote:
> > > > Hi!
> > > >
> > > >>> It boots ok (unlike mainline -- I'm debugging that), and I can suspend
>
On Wed 2019-04-24 11:54:31, Pavel Machek wrote:
> On Tue 2019-04-23 07:55:05, Jens Axboe wrote:
> > On 4/23/19 4:22 AM, Pavel Machek wrote:
> > > Hi!
> > >
> > >>> It boots ok (unlike mainline -- I'm debugging that), and I can suspend
> > >>> and resume... but then cursor in X is moving and I can
On Tue 2019-04-23 07:09:42, Bart Van Assche wrote:
> On 4/23/19 3:22 AM, Pavel Machek wrote:
> >>> It boots ok (unlike mainline -- I'm debugging that), and I can suspend
> >>> and resume... but then cursor in X is moving and I can talk to
> >>> applications cached in memory, but any access to disk
On Tue 2019-04-23 07:55:05, Jens Axboe wrote:
> On 4/23/19 4:22 AM, Pavel Machek wrote:
> > Hi!
> >
> >>> It boots ok (unlike mainline -- I'm debugging that), and I can suspend
> >>> and resume... but then cursor in X is moving and I can talk to
> >>> applications cached in memory, but any access
On Tue 2019-04-23 07:55:05, Jens Axboe wrote:
> On 4/23/19 4:22 AM, Pavel Machek wrote:
> > Hi!
> >
> >>> It boots ok (unlike mainline -- I'm debugging that), and I can suspend
> >>> and resume... but then cursor in X is moving and I can talk to
> >>> applications cached in memory, but any access
On 4/23/19 3:22 AM, Pavel Machek wrote:
>>> It boots ok (unlike mainline -- I'm debugging that), and I can suspend
>>> and resume... but then cursor in X is moving and I can talk to
>>> applications cached in memory, but any access to disk hangs.
>>
>> Mainline problem was identified.
>>
>> But
On 4/23/19 4:22 AM, Pavel Machek wrote:
> Hi!
>
>>> It boots ok (unlike mainline -- I'm debugging that), and I can suspend
>>> and resume... but then cursor in X is moving and I can talk to
>>> applications cached in memory, but any access to disk hangs.
>>
>> Mainline problem was identified.
>>
Hi!
> > It boots ok (unlike mainline -- I'm debugging that), and I can suspend
> > and resume... but then cursor in X is moving and I can talk to
> > applications cached in memory, but any access to disk hangs.
>
> Mainline problem was identified.
>
> But resume is still broken. I took
Hi!
> It boots ok (unlike mainline -- I'm debugging that), and I can suspend
> and resume... but then cursor in X is moving and I can talk to
> applications cached in memory, but any access to disk hangs.
Mainline problem was identified.
But resume is still broken. I took advantage of fact that
Hi!
It boots ok (unlike mainline -- I'm debugging that), and I can suspend
and resume... but then cursor in X is moving and I can talk to
applications cached in memory, but any access to disk hangs.
Any ideas?
Pavel
--
Rafael J. Wysocki wrote:
>>
>> After all I think all this problems may be some who ACPI related
>> but the question is why they get triggered by Suspend/Hibernation.
>
> They certainly are ACPI-related, because the only difference between level 4
> and level 3 suspend testing is that some global
Rafael J. Wysocki wrote:
After all I think all this problems may be some who ACPI related
but the question is why they get triggered by Suspend/Hibernation.
They certainly are ACPI-related, because the only difference between level 4
and level 3 suspend testing is that some global ACPI
On Tuesday, 23 October 2007 03:01, Gabriel C wrote:
>
> > Also box just froze on level 3 but I got a ACPI error at least which I
> > didn't got in any other dmesg till now :
> > ( also patch was tested with HT disabled and Suspend and Hibernation
> > enabled in kernel and BIOS )
> >
> > ...
>
On Tue, 23 Oct 2007, Rafael J. Wysocki wrote:
> On Monday, 22 October 2007 16:11, Mark Lord wrote:
> > Rafael,
> >
> > What happens to the jiffies variable on resume from RAM, and from DISK?
> > Do we restore it to the value it had at suspend,
> > or just leave it be with whatever?
> >
> > The
On Tue, 23 Oct 2007, Rafael J. Wysocki wrote:
On Monday, 22 October 2007 16:11, Mark Lord wrote:
Rafael,
What happens to the jiffies variable on resume from RAM, and from DISK?
Do we restore it to the value it had at suspend,
or just leave it be with whatever?
The answer has to
On Tuesday, 23 October 2007 03:01, Gabriel C wrote:
Also box just froze on level 3 but I got a ACPI error at least which I
didn't got in any other dmesg till now :
( also patch was tested with HT disabled and Suspend and Hibernation
enabled in kernel and BIOS )
...
Oct 23
> Also box just froze on level 3 but I got a ACPI error at least which I didn't
> got in any other dmesg till now :
> ( also patch was tested with HT disabled and Suspend and Hibernation enabled
> in kernel and BIOS )
>
> ...
>
> Oct 23 01:51:05 lara [ 273.512374] PM: Removing info for No
Gabriel C wrote:
> Rafael J. Wysocki wrote:
>> On Tuesday, 23 October 2007 01:00, Gabriel C wrote:
>>> Rafael J. Wysocki wrote:
On Monday, 22 October 2007 18:15, Gabriel C wrote:
> Hi all ,
>
> I'm running current git + aic7xxx suspend patch from
>
Rafael J. Wysocki wrote:
> On Tuesday, 23 October 2007 01:00, Gabriel C wrote:
>> Rafael J. Wysocki wrote:
>>> On Monday, 22 October 2007 18:15, Gabriel C wrote:
Hi all ,
I'm running current git + aic7xxx suspend patch from
http://bugzilla.kernel.org/show_bug.cgi?id=3062
On Tuesday, 23 October 2007 01:00, Gabriel C wrote:
> Rafael J. Wysocki wrote:
> > On Monday, 22 October 2007 18:15, Gabriel C wrote:
> >> Hi all ,
> >>
> >> I'm running current git + aic7xxx suspend patch from
> >> http://bugzilla.kernel.org/show_bug.cgi?id=3062
> >> on a Dell Precision
Rafael J. Wysocki wrote:
> On Monday, 22 October 2007 18:15, Gabriel C wrote:
>> Hi all ,
>>
>> I'm running current git + aic7xxx suspend patch from
>> http://bugzilla.kernel.org/show_bug.cgi?id=3062
>> on a Dell Precision WorkStation 530 MT SMP box ( HT enabled ).
>>
>> Suspend works fine but
On Monday, 22 October 2007 16:11, Mark Lord wrote:
> Rafael,
>
> What happens to the jiffies variable on resume from RAM, and from DISK?
> Do we restore it to the value it had at suspend,
> or just leave it be with whatever?
>
> The answer has to be "restore the value it had at suspend time",
>
On Monday, 22 October 2007 18:15, Gabriel C wrote:
> Hi all ,
>
> I'm running current git + aic7xxx suspend patch from
> http://bugzilla.kernel.org/show_bug.cgi?id=3062
> on a Dell Precision WorkStation 530 MT SMP box ( HT enabled ).
>
> Suspend works fine but on resume I have some problems.
Hi all ,
I'm running current git + aic7xxx suspend patch from
http://bugzilla.kernel.org/show_bug.cgi?id=3062
on a Dell Precision WorkStation 530 MT SMP box ( HT enabled ).
Suspend works fine but on resume I have some problems.
All CPU's but boot CPU won't come back , everything else seems
Rafael,
What happens to the jiffies variable on resume from RAM, and from DISK?
Do we restore it to the value it had at suspend,
or just leave it be with whatever?
The answer has to be "restore the value it had at suspend time",
but I figured I'd check here anyway.
??
-
To unsubscribe from
Rafael,
What happens to the jiffies variable on resume from RAM, and from DISK?
Do we restore it to the value it had at suspend,
or just leave it be with whatever?
The answer has to be restore the value it had at suspend time,
but I figured I'd check here anyway.
??
-
To unsubscribe from this
Hi all ,
I'm running current git + aic7xxx suspend patch from
http://bugzilla.kernel.org/show_bug.cgi?id=3062
on a Dell Precision WorkStation 530 MT SMP box ( HT enabled ).
Suspend works fine but on resume I have some problems.
All CPU's but boot CPU won't come back , everything else seems
On Monday, 22 October 2007 18:15, Gabriel C wrote:
Hi all ,
I'm running current git + aic7xxx suspend patch from
http://bugzilla.kernel.org/show_bug.cgi?id=3062
on a Dell Precision WorkStation 530 MT SMP box ( HT enabled ).
Suspend works fine but on resume I have some problems.
All
On Monday, 22 October 2007 16:11, Mark Lord wrote:
Rafael,
What happens to the jiffies variable on resume from RAM, and from DISK?
Do we restore it to the value it had at suspend,
or just leave it be with whatever?
The answer has to be restore the value it had at suspend time,
but I
Rafael J. Wysocki wrote:
On Monday, 22 October 2007 18:15, Gabriel C wrote:
Hi all ,
I'm running current git + aic7xxx suspend patch from
http://bugzilla.kernel.org/show_bug.cgi?id=3062
on a Dell Precision WorkStation 530 MT SMP box ( HT enabled ).
Suspend works fine but on resume I have
On Tuesday, 23 October 2007 01:00, Gabriel C wrote:
Rafael J. Wysocki wrote:
On Monday, 22 October 2007 18:15, Gabriel C wrote:
Hi all ,
I'm running current git + aic7xxx suspend patch from
http://bugzilla.kernel.org/show_bug.cgi?id=3062
on a Dell Precision WorkStation 530 MT SMP
Rafael J. Wysocki wrote:
On Tuesday, 23 October 2007 01:00, Gabriel C wrote:
Rafael J. Wysocki wrote:
On Monday, 22 October 2007 18:15, Gabriel C wrote:
Hi all ,
I'm running current git + aic7xxx suspend patch from
http://bugzilla.kernel.org/show_bug.cgi?id=3062
on a Dell Precision
Gabriel C wrote:
Rafael J. Wysocki wrote:
On Tuesday, 23 October 2007 01:00, Gabriel C wrote:
Rafael J. Wysocki wrote:
On Monday, 22 October 2007 18:15, Gabriel C wrote:
Hi all ,
I'm running current git + aic7xxx suspend patch from
http://bugzilla.kernel.org/show_bug.cgi?id=3062
on a
Also box just froze on level 3 but I got a ACPI error at least which I didn't
got in any other dmesg till now :
( also patch was tested with HT disabled and Suspend and Hibernation enabled
in kernel and BIOS )
...
Oct 23 01:51:05 lara [ 273.512374] PM: Removing info for No Bus:input0
Pavel Machek wrote:
Hi!
Since upgrading to 2.6.23.1 from 2.6.23-rc9,
resume-from-RAM has been misbehaving here.
It takes much (+5-7 seconds) longer to resume
*sometimes*, but not all/most of the time.
I suspend those long delays may have something to do with USB,
as it takes longer for my
Hi!
> Since upgrading to 2.6.23.1 from 2.6.23-rc9,
> resume-from-RAM has been misbehaving here.
>
> It takes much (+5-7 seconds) longer to resume
> *sometimes*, but not all/most of the time.
> And sometimes I get get flashing keyboard LEDs and have
> to hold the power button
> in for a full
Hi!
Since upgrading to 2.6.23.1 from 2.6.23-rc9,
resume-from-RAM has been misbehaving here.
It takes much (+5-7 seconds) longer to resume
*sometimes*, but not all/most of the time.
And sometimes I get get flashing keyboard LEDs and have
to hold the power button
in for a full hard
Pavel Machek wrote:
Hi!
Since upgrading to 2.6.23.1 from 2.6.23-rc9,
resume-from-RAM has been misbehaving here.
It takes much (+5-7 seconds) longer to resume
*sometimes*, but not all/most of the time.
I suspend those long delays may have something to do with USB,
as it takes longer for my
On Wednesday, 17 October 2007 00:10, Mark Lord wrote:
> Mark Lord wrote:
> > Rafael J. Wysocki wrote:
> >> On Sunday, 14 October 2007 22:13, Mark Lord wrote:
> >>> Since upgrading to 2.6.23.1 from 2.6.23-rc9, resume-from-RAM has been
> >>> misbehaving here.
> >>>
> >>> It takes much (+5-7
Mark Lord wrote:
Rafael J. Wysocki wrote:
On Sunday, 14 October 2007 22:13, Mark Lord wrote:
Since upgrading to 2.6.23.1 from 2.6.23-rc9, resume-from-RAM has been
misbehaving here.
It takes much (+5-7 seconds) longer to resume *sometimes*, but not
all/most of the time.
And sometimes I get
Mark Lord wrote:
Rafael J. Wysocki wrote:
On Sunday, 14 October 2007 22:13, Mark Lord wrote:
Since upgrading to 2.6.23.1 from 2.6.23-rc9, resume-from-RAM has been
misbehaving here.
It takes much (+5-7 seconds) longer to resume *sometimes*, but not
all/most of the time.
And sometimes I get
On Wednesday, 17 October 2007 00:10, Mark Lord wrote:
Mark Lord wrote:
Rafael J. Wysocki wrote:
On Sunday, 14 October 2007 22:13, Mark Lord wrote:
Since upgrading to 2.6.23.1 from 2.6.23-rc9, resume-from-RAM has been
misbehaving here.
It takes much (+5-7 seconds) longer to resume
Rafael J. Wysocki wrote:
On Sunday, 14 October 2007 22:13, Mark Lord wrote:
Since upgrading to 2.6.23.1 from 2.6.23-rc9, resume-from-RAM has been
misbehaving here.
It takes much (+5-7 seconds) longer to resume *sometimes*, but not all/most of
the time.
And sometimes I get get flashing
On Sunday, 14 October 2007 22:13, Mark Lord wrote:
> Since upgrading to 2.6.23.1 from 2.6.23-rc9, resume-from-RAM has been
> misbehaving here.
>
> It takes much (+5-7 seconds) longer to resume *sometimes*, but not all/most
> of the time.
> And sometimes I get get flashing keyboard LEDs and have
Since upgrading to 2.6.23.1 from 2.6.23-rc9, resume-from-RAM has been
misbehaving here.
It takes much (+5-7 seconds) longer to resume *sometimes*, but not all/most of
the time.
And sometimes I get get flashing keyboard LEDs and have to hold the power button
in for a full hard reset.
With
Since upgrading to 2.6.23.1 from 2.6.23-rc9, resume-from-RAM has been
misbehaving here.
It takes much (+5-7 seconds) longer to resume *sometimes*, but not all/most of
the time.
And sometimes I get get flashing keyboard LEDs and have to hold the power button
in for a full hard reset.
With
On Sunday, 14 October 2007 22:13, Mark Lord wrote:
Since upgrading to 2.6.23.1 from 2.6.23-rc9, resume-from-RAM has been
misbehaving here.
It takes much (+5-7 seconds) longer to resume *sometimes*, but not all/most
of the time.
And sometimes I get get flashing keyboard LEDs and have to
Rafael J. Wysocki wrote:
On Sunday, 14 October 2007 22:13, Mark Lord wrote:
Since upgrading to 2.6.23.1 from 2.6.23-rc9, resume-from-RAM has been
misbehaving here.
It takes much (+5-7 seconds) longer to resume *sometimes*, but not all/most of
the time.
And sometimes I get get flashing
On Wed 2007-07-25 20:20:42, Richard Purdie wrote:
> On Wed, 2007-07-25 at 19:01 +, Pavel Machek wrote:
> > > I enabled the MMC_UNSAFE_RESUME option and the problems I was seeing was
> > > "fixed". I think having this option is a bad idea (in its current form)
> > > as it doesn't actually stop
On Wed, 2007-07-25 at 19:01 +, Pavel Machek wrote:
> > I enabled the MMC_UNSAFE_RESUME option and the problems I was seeing was
> > "fixed". I think having this option is a bad idea (in its current form)
> > as it doesn't actually stop filesystem corruption.
> >
> > With the option disabled,
Hi!
> > > Lots of Linux handhelds use MMC/SD devices as the root file system.
> > > This has worked quite reliably for many kernel versions. In 2.6.22,
> > > it seems that if you suspend such a system then resume it, the device
> > > locks up. Trying to execute anything on the filesystem results
On Wed 2007-07-25 20:20:42, Richard Purdie wrote:
On Wed, 2007-07-25 at 19:01 +, Pavel Machek wrote:
I enabled the MMC_UNSAFE_RESUME option and the problems I was seeing was
fixed. I think having this option is a bad idea (in its current form)
as it doesn't actually stop filesystem
On Wed, 2007-07-25 at 19:01 +, Pavel Machek wrote:
I enabled the MMC_UNSAFE_RESUME option and the problems I was seeing was
fixed. I think having this option is a bad idea (in its current form)
as it doesn't actually stop filesystem corruption.
With the option disabled, if a
Hi!
Lots of Linux handhelds use MMC/SD devices as the root file system.
This has worked quite reliably for many kernel versions. In 2.6.22,
it seems that if you suspend such a system then resume it, the device
locks up. Trying to execute anything on the filesystem results in a
On Sun, 22 Jul 2007 15:28:00 +0100
Richard Purdie <[EMAIL PROTECTED]> wrote:
>
> Corruption is corruption and it shouldn't happen if we can avoid it.
> It happens with complete certainty in one case and only happens in the
> other if the user does something which is a fairly obvious bad idea
>
On Sun, 2007-07-22 at 16:05 +0200, Pierre Ossman wrote:
> On Sun, 22 Jul 2007 14:18:33 +0100
> Richard Purdie <[EMAIL PROTECTED]> wrote:
> > I enabled the MMC_UNSAFE_RESUME option and the problems I was seeing
> > was "fixed". I think having this option is a bad idea (in its current
> > form) as
On Sun, 22 Jul 2007 14:18:33 +0100
Richard Purdie <[EMAIL PROTECTED]> wrote:
>
> I enabled the MMC_UNSAFE_RESUME option and the problems I was seeing
> was "fixed". I think having this option is a bad idea (in its current
> form) as it doesn't actually stop filesystem corruption.
>
> With the
On Thu, 2007-07-19 at 19:03 +0200, Pierre Ossman wrote:
> On Thu, 19 Jul 2007 16:53:39 +0100
> Richard Purdie <[EMAIL PROTECTED]> wrote:
> > Lots of Linux handhelds use MMC/SD devices as the root file system.
> > This has worked quite reliably for many kernel versions. In 2.6.22,
> > it seems that
On Thu, 2007-07-19 at 19:03 +0200, Pierre Ossman wrote:
On Thu, 19 Jul 2007 16:53:39 +0100
Richard Purdie [EMAIL PROTECTED] wrote:
Lots of Linux handhelds use MMC/SD devices as the root file system.
This has worked quite reliably for many kernel versions. In 2.6.22,
it seems that if you
On Sun, 22 Jul 2007 14:18:33 +0100
Richard Purdie [EMAIL PROTECTED] wrote:
I enabled the MMC_UNSAFE_RESUME option and the problems I was seeing
was fixed. I think having this option is a bad idea (in its current
form) as it doesn't actually stop filesystem corruption.
With the option
On Sun, 2007-07-22 at 16:05 +0200, Pierre Ossman wrote:
On Sun, 22 Jul 2007 14:18:33 +0100
Richard Purdie [EMAIL PROTECTED] wrote:
I enabled the MMC_UNSAFE_RESUME option and the problems I was seeing
was fixed. I think having this option is a bad idea (in its current
form) as it doesn't
On Sun, 22 Jul 2007 15:28:00 +0100
Richard Purdie [EMAIL PROTECTED] wrote:
Corruption is corruption and it shouldn't happen if we can avoid it.
It happens with complete certainty in one case and only happens in the
other if the user does something which is a fairly obvious bad idea
(which
On Thu, 19 Jul 2007 16:53:39 +0100
Richard Purdie <[EMAIL PROTECTED]> wrote:
> Hi Pierre,
>
> Lots of Linux handhelds use MMC/SD devices as the root file system.
> This has worked quite reliably for many kernel versions. In 2.6.22,
> it seems that if you suspend such a system then resume it, the
On Thu, 2007-07-19 at 16:57 +0100, Richard Purdie wrote:
> Lots of Linux handhelds use MMC/SD devices as the root file system. This
> has worked quite reliably for many kernel versions. In 2.6.22, it seems
> that if you suspend such a system then resume it, the device locks up.
> Trying to execute
Hi Pierre,
Lots of Linux handhelds use MMC/SD devices as the root file system. This
has worked quite reliably for many kernel versions. In 2.6.22, it seems
that if you suspend such a system then resume it, the device locks up.
Trying to execute anything on the filesystem results in a "Permission
Hi Pierre,
Lots of Linux handhelds use MMC/SD devices as the root file system. This
has worked quite reliably for many kernel versions. In 2.6.22, it seems
that if you suspend such a system then resume it, the device locks up.
Trying to execute anything on the filesystem results in a Permission
On Thu, 2007-07-19 at 16:57 +0100, Richard Purdie wrote:
Lots of Linux handhelds use MMC/SD devices as the root file system. This
has worked quite reliably for many kernel versions. In 2.6.22, it seems
that if you suspend such a system then resume it, the device locks up.
Trying to execute
On Thu, 19 Jul 2007 16:53:39 +0100
Richard Purdie [EMAIL PROTECTED] wrote:
Hi Pierre,
Lots of Linux handhelds use MMC/SD devices as the root file system.
This has worked quite reliably for many kernel versions. In 2.6.22,
it seems that if you suspend such a system then resume it, the device
> Date: Fri, 19 Aug 2005 08:39:25 -0600
> From: "William Morrow" <[EMAIL PROTECTED]>
> Subject: [PATCH] for acpi S1 power cycle resume problems
>
>
> Hi
> I was told that if I had a patch to submit for a baseline change that
> this was the place to do it.
Date: Fri, 19 Aug 2005 08:39:25 -0600
From: William Morrow [EMAIL PROTECTED]
Subject: [PATCH] for acpi S1 power cycle resume problems
Hi
I was told that if I had a patch to submit for a baseline change that
this was the place to do it.
In this case that works fine. Normally they should
Hi
I was told that if I had a patch to submit for a baseline change that
this was the place to do it.
If not, please let me know...
thanks,
morrow
Patched against 2.6.11 baseline
problems fixed:
1) OHCI_INTR_RD not being cleared in ohci interrupt handler
results in interrupt storm and system
Hi
I was told that if I had a patch to submit for a baseline change that
this was the place to do it.
If not, please let me know...
thanks,
morrow
Patched against 2.6.11 baseline
problems fixed:
1) OHCI_INTR_RD not being cleared in ohci interrupt handler
results in interrupt storm and system
Hello Dave,
after suspend-to-ram and a subsequent resume the configuration
of my AGP bridge/controller is different and X will refuse to
start after resume if it wasn't running during suspend. I'm
using radeonfb as console driver and kernel 2.6.13-rc6-git6.
Diff between lspci -vvvxxx before and
Hello Dave,
after suspend-to-ram and a subsequent resume the configuration
of my AGP bridge/controller is different and X will refuse to
start after resume if it wasn't running during suspend. I'm
using radeonfb as console driver and kernel 2.6.13-rc6-git6.
Diff between lspci -vvvxxx before and
Though it looks a lot better; no more streams of messages.
Now when I resume, I get:
PCI: Enabling device :00:1d.7 ( -> 0002)
<1>Unable to handle kernel NULL pointer dereference
a second or so after resume. It is completely locked up at this point;
magic-sysreq gets no response.
lspci
Though it looks a lot better; no more streams of messages.
Now when I resume, I get:
PCI: Enabling device :00:1d.7 ( - 0002)
1Unable to handle kernel NULL pointer dereference
a second or so after resume. It is completely locked up at this point;
magic-sysreq gets no response.
lspci
On Sat, Mar 19, 2005 at 01:44:24AM -0800, Jeremy Fitzhardinge wrote:
> On my IBM ThinkPad X31, I can only do one successful APM resume. After
> the resume, there's a stream of messages on the console:
>
> uhci_hcd :00:1d.0: host controller process error, something bad
> happened!
>
On my IBM ThinkPad X31, I can only do one successful APM resume. After
the resume, there's a stream of messages on the console:
uhci_hcd :00:1d.0: host controller process error, something bad happened!
uhci_hcd :00:1d.0: host system error, PCI problems?
uhci_hcd :00:1d.0: host
On my IBM ThinkPad X31, I can only do one successful APM resume. After
the resume, there's a stream of messages on the console:
uhci_hcd :00:1d.0: host controller process error, something bad happened!
uhci_hcd :00:1d.0: host system error, PCI problems?
uhci_hcd :00:1d.0: host
On Sat, Mar 19, 2005 at 01:44:24AM -0800, Jeremy Fitzhardinge wrote:
On my IBM ThinkPad X31, I can only do one successful APM resume. After
the resume, there's a stream of messages on the console:
uhci_hcd :00:1d.0: host controller process error, something bad
happened!
uhci_hcd
On Tue, 8 Mar 2005 22:55:37 +0100
Pavel Machek <[EMAIL PROTECTED]> wrote:
> Any idea what to do there? I'd say that request_irq is very unlikely
> to fail given that it worked okay before suspend...
What you have is fine for now.
It is just a general issue that ->resume() has no way to cleanly
Hi!
> > @@ -1934,6 +1936,9 @@
> > if (!netif_running(dev))
> > return 0;
> >
> > + if (request_irq(dev->irq, b44_interrupt, SA_SHIRQ, dev->name, dev))
> > + printk(KERN_ERR PFX "%s: request_irq failed\n", dev->name);
> > +
>
> This is a hard error and means that
On Tue, 8 Mar 2005 10:46:55 +0100
Pavel Machek <[EMAIL PROTECTED]> wrote:
> @@ -1934,6 +1936,9 @@
> if (!netif_running(dev))
> return 0;
>
> + if (request_irq(dev->irq, b44_interrupt, SA_SHIRQ, dev->name, dev))
> + printk(KERN_ERR PFX "%s: request_irq
Hi!
This should fix problems people have with b44 during
suspend/resume. Please apply,
Pavel
--- clean/drivers/net/b44.c 2004-12-25 13:35:00.0 +0100
+++ linux/drivers/net/b44.c 2005-01-19 11:59:12.0 +0100
@@
Hi!
This should fix problems people have with b44 during
suspend/resume. Please apply,
Pavel
--- clean/drivers/net/b44.c 2004-12-25 13:35:00.0 +0100
+++ linux/drivers/net/b44.c 2005-01-19 11:59:12.0 +0100
@@
On Tue, 8 Mar 2005 10:46:55 +0100
Pavel Machek [EMAIL PROTECTED] wrote:
@@ -1934,6 +1936,9 @@
if (!netif_running(dev))
return 0;
+ if (request_irq(dev-irq, b44_interrupt, SA_SHIRQ, dev-name, dev))
+ printk(KERN_ERR PFX %s: request_irq failed\n,
Hi!
@@ -1934,6 +1936,9 @@
if (!netif_running(dev))
return 0;
+ if (request_irq(dev-irq, b44_interrupt, SA_SHIRQ, dev-name, dev))
+ printk(KERN_ERR PFX %s: request_irq failed\n, dev-name);
+
This is a hard error and means that bringup of the chip
On Tue, 8 Mar 2005 22:55:37 +0100
Pavel Machek [EMAIL PROTECTED] wrote:
Any idea what to do there? I'd say that request_irq is very unlikely
to fail given that it worked okay before suspend...
What you have is fine for now.
It is just a general issue that -resume() has no way to cleanly
fail.
97 matches
Mail list logo
