[email protected] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=10345
>
>
> [email protected] changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> Status|NEW |REJECTED
> Resolution| |UNREPRODUCIBLE
>
>
>
>
> ------- Comment #2 from [email protected] 2008-03-28 15:35 -------
> Handled-By : Mark Lord <[email protected]>
> References : http://lkml.org/lkml/2008/3/28/346
>
> Mark said:
>
> "Also, for now it seems to be "resolved" via a seemingly-unrelated
> change in the .config file on that machine. If it dies again,
> I'll re-post and investigate further."
..
Just happened again. The machine resumed from RAM with no functioning USB.
Still running the exact same 2.6.25-rc7 kernel as before, with the RTC conflict fixed.
WTF?
On Sat, 29 Mar 2008, Mark Lord wrote:
> Just happened again. The machine resumed from RAM with no functioning USB.
> Still running the exact same 2.6.25-rc7 kernel as before, with the RTC conflict fixed.
>
> WTF?
The first step in debugging this is to build a kernel with
CONFIG_USB_DEBUG and send the dmesg log following an unsuccessful
resume. Include events from before the suspend; don't strip them out.
If the symptoms are the same as before then you should also get a stack
dump for the ksuspend_usbd task.
Alan Stern
Am Samstag, 29. März 2008 18:15:40 schrieb Mark Lord:
> [email protected] wrote:
> > http://bugzilla.kernel.org/show_bug.cgi?id=10345
> >
> >
> > [email protected] changed:
> >
> > What |Removed |Added
> > ----------------------------------------------------------------------------
> > Status|NEW |REJECTED
> > Resolution| |UNREPRODUCIBLE
> >
> >
> >
> >
> > ------- Comment #2 from [email protected] 2008-03-28 15:35 -------
> > Handled-By : Mark Lord <[email protected]>
> > References : http://lkml.org/lkml/2008/3/28/346
> >
> > Mark said:
> >
> > "Also, for now it seems to be "resolved" via a seemingly-unrelated
> > change in the .config file on that machine. If it dies again,
> > I'll re-post and investigate further."
> ..
>
> Just happened again. The machine resumed from RAM with no functioning USB.
> Still running the exact same 2.6.25-rc7 kernel as before, with the RTC conflict fixed.
>
> WTF?
Is khubd stuck in D state?
Regards
Oliver
On Sat 2008-03-29 13:15:40, Mark Lord wrote:
> [email protected] wrote:
>> http://bugzilla.kernel.org/show_bug.cgi?id=10345
>>
>>
>> [email protected] changed:
>>
>> What |Removed |Added
>> ----------------------------------------------------------------------------
>> Status|NEW |REJECTED
>> Resolution| |UNREPRODUCIBLE
>>
>>
>>
>>
>> ------- Comment #2 from [email protected] 2008-03-28 15:35 -------
>> Handled-By : Mark Lord <[email protected]>
>> References : http://lkml.org/lkml/2008/3/28/346
>>
>> Mark said:
>>
>> "Also, for now it seems to be "resolved" via a seemingly-unrelated
>> change in the .config file on that machine. If it dies again,
>> I'll re-post and investigate further."
> ..
>
> Just happened again. The machine resumed from RAM with no functioning USB.
> Still running the exact same 2.6.25-rc7 kernel as before, with the RTC conflict fixed.
>
> WTF?
>3GB of RAM? Try iommu=soft.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Pavel Machek wrote:
> On Sat 2008-03-29 13:15:40, Mark Lord wrote:
>..
>> Just happened again. The machine resumed from RAM with no functioning USB.
>> Still running the exact same 2.6.25-rc7 kernel as before, with the RTC conflict fixed.
>>
>> WTF?
>
>> 3GB of RAM? Try iommu=soft.
..
What does that option do (it is not in Documentation/kernel-parameters.txt),
and why do you suspect it may make a difference here?
Thanks
On Sun 2008-03-30 13:46:25, Mark Lord wrote:
> Pavel Machek wrote:
>> On Sat 2008-03-29 13:15:40, Mark Lord wrote:
>> ..
>>> Just happened again. The machine resumed from RAM with no functioning USB.
>>> Still running the exact same 2.6.25-rc7 kernel as before, with the RTC conflict fixed.
>>>
>>> WTF?
>>
>>> 3GB of RAM? Try iommu=soft.
> ..
>
> What does that option do (it is not in Documentation/kernel-parameters.txt),
> and why do you suspect it may make a difference here?
See x86_64/boot-options.txt . Yes, that should be fixed.
I had strange problems, and it looks like iommu does not have proper
suspend/resume support. > 3GB machines hit that. Do you have one?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Pavel Machek wrote:
> On Sun 2008-03-30 13:46:25, Mark Lord wrote:
>> Pavel Machek wrote:
>>> On Sat 2008-03-29 13:15:40, Mark Lord wrote:
>>> ..
>>>> Just happened again. The machine resumed from RAM with no functioning USB.
>>>> Still running the exact same 2.6.25-rc7 kernel as before, with the RTC conflict fixed.
>>>>
>>>> WTF?
>>>> 3GB of RAM? Try iommu=soft.
>> ..
>>
>> What does that option do (it is not in Documentation/kernel-parameters.txt),
>> and why do you suspect it may make a difference here?
>
> See x86_64/boot-options.txt . Yes, that should be fixed.
>
> I had strange problems, and it looks like iommu does not have proper
> suspend/resume support. > 3GB machines hit that. Do you have one?
..
This is a 32-bit system / kernel, so I'm guessing that this option is not applicable.
Right? (it does have 3GB of RAM, though).
Cheers
On Sun 2008-03-30 16:15:50, Mark Lord wrote:
> Pavel Machek wrote:
>> On Sun 2008-03-30 13:46:25, Mark Lord wrote:
>>> Pavel Machek wrote:
>>>> On Sat 2008-03-29 13:15:40, Mark Lord wrote:
>>>> ..
>>>>> Just happened again. The machine resumed from RAM with no functioning USB.
>>>>> Still running the exact same 2.6.25-rc7 kernel as before, with the RTC conflict fixed.
>>>>>
>>>>> WTF?
>>>>> 3GB of RAM? Try iommu=soft.
>>> ..
>>>
>>> What does that option do (it is not in Documentation/kernel-parameters.txt),
>>> and why do you suspect it may make a difference here?
>>
>> See x86_64/boot-options.txt . Yes, that should be fixed.
>>
>> I had strange problems, and it looks like iommu does not have proper
>> suspend/resume support. > 3GB machines hit that. Do you have one?
> ..
>
> This is a 32-bit system / kernel, so I'm guessing that this option is not applicable.
>
> Right? (it does have 3GB of RAM, though).
Not 100% sure... I've seen strangeness on 32-bit systems, too. Can you
simply pass mem=2G and see what happens?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>>>>>> 3GB of RAM? Try iommu=soft.
..
>>
>> This is a 32-bit system / kernel, so I'm guessing that this option is not applicable.
>>
>> Right? (it does have 3GB of RAM, though).
>
> Not 100% sure... I've seen strangeness on 32-bit systems, too. Can you
> simply pass mem=2G and see what happens?
..
Sure, after I finish collecting data on the problem, I'll give that a try.
It will be somewhat inconclusive, though, since the problem does not happen
on every resume.
cheers