Hi.
On Fri, 2005-08-05 at 07:45, Pavel Machek wrote:
> Hi!
>
> > > > > > Good question. I'm not certain if Pavel intended to add
> > > > > > device_suspend(PMSG_FREEZE) to the reboot path. It was
> > > > > > there in only one instance. Pavel comments talk only about
> > > > > > the suspend
Hi!
> > > > > Good question. I'm not certain if Pavel intended to add
> > > > > device_suspend(PMSG_FREEZE) to the reboot path. It was
> > > > > there in only one instance. Pavel comments talk only about
> > > > > the suspend path.
> > > >
> > > > Yes, I think we should do device_suspend(
Hi.
On Thu, 2005-07-28 at 08:54, Pavel Machek wrote:
> Hi!
>
> > > > Good question. I'm not certain if Pavel intended to add
> > > > device_suspend(PMSG_FREEZE) to the reboot path. It was
> > > > there in only one instance. Pavel comments talk only about
> > > > the suspend path.
> > >
>
Pavel Machek <[EMAIL PROTECTED]> writes:
> I always thought that device_shutdown is different phase -- the one
> with interrupts disabled...
At the end of device_shutdown interrupts are disabled because we
shutdown the interrupt controllers.
I don't think we have a phase where the interrupts
Pavel Machek <[EMAIL PROTECTED]> writes:
> Hi!
>
>> So unless you are really ambitious I'd like to take
>> device_suspend(PMSG_FREEZE) out of the reboot path for
>> 2.6.13, put in -mm where people can bang on it for a bit
>> and see that it is coming and delay the merge with the stable
>> branch u
Pavel Machek <[EMAIL PROTECTED]> writes:
> I always thought that device_shutdown is different phase -- the one
> with interrupts disabled...
Nope. device_shutdown runs before interrupts are disabled.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Hi!
> So unless you are really ambitious I'd like to take
> device_suspend(PMSG_FREEZE) out of the reboot path for
> 2.6.13, put in -mm where people can bang on it for a bit
> and see that it is coming and delay the merge with the stable
> branch until the bugs with common hardware have been sorte
Hi!
> >> > Yes, I think we should do device_suspend(PMSG_FREEZE) in reboot path.
> >>
> >> Considering how many device drivers that are likely broken, I disagree.
> >> Especially since Andrew seems to have trivially found a machine where it
> >> doesn't work.
> >
> > I'm not sure if we want to
Pavel Machek <[EMAIL PROTECTED]> writes:
> Hi!
>
>> > Yes, I think we should do device_suspend(PMSG_FREEZE) in reboot path.
>>
>> Considering how many device drivers that are likely broken, I disagree.
>> Especially since Andrew seems to have trivially found a machine where it
>> doesn't work.
Pavel Machek <[EMAIL PROTECTED]> writes:
> Hi!
>
> Yes, I think we should do device_suspend(PMSG_FREEZE) in reboot path.
>
>> My gut feel is the device_suspend calls are the right direction
>> as it allows us to remove code from the drivers and possible
>> kill device_shutdown completely.
>>
>>
Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> > Good question. I'm not certain if Pavel intended to add
> > device_suspend(PMSG_FREEZE) to the reboot path. It was
> > there in only one instance. Pavel comments talk only about
> > the suspend path.
>
> Yes, I think we should do device_suspend
Hi!
> > > Good question. I'm not certain if Pavel intended to add
> > > device_suspend(PMSG_FREEZE) to the reboot path. It was
> > > there in only one instance. Pavel comments talk only about
> > > the suspend path.
> >
> > Yes, I think we should do device_suspend(PMSG_FREEZE) in reboot p
Hi!
> > Yes, I think we should do device_suspend(PMSG_FREEZE) in reboot path.
>
> Considering how many device drivers that are likely broken, I disagree.
> Especially since Andrew seems to have trivially found a machine where it
> doesn't work.
I'm not sure if we want to do that for 2.6.13, bu
On Thu, 28 Jul 2005, Pavel Machek wrote:
>
> Yes, I think we should do device_suspend(PMSG_FREEZE) in reboot path.
Considering how many device drivers that are likely broken, I disagree.
Especially since Andrew seems to have trivially found a machine where it
doesn't work.
Li
Hi!
> >> > My fairly ordinary x86 test box gets stuck during reboot on the
> >> > wait_for_completion() in ide_do_drive_cmd():
> >>
> >> Hmm. The only thing I can think of is someone started adding calls
> >> to device_suspend() before device_shutdown(). Not understanding
> >> where it was
Andrew Morton <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Eric W. Biederman) wrote:
>
> By "fixed" do you mean Tony Luck's patch which I added to rc3-mm2? If so,
> do you think that's needed for 2.6.13? Getting patches into e100[0] is a
> bit of an exercise :(
That is what I was referring
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
>
> Andrew Morton <[EMAIL PROTECTED]> writes:
>
> > [EMAIL PROTECTED] (Eric W. Biederman) wrote:
> >>
> >> Andrew Morton <[EMAIL PROTECTED]> writes:
> >>
> >> > My fairly ordinary x86 test box gets stuck during reboot on the
> >> > wait_for_completio
[EMAIL PROTECTED] (Eric W. Biederman) writes:
> We really need to get a consistent set of requirements
> for the device driver authors so they have a chance of
> catching up.
I meant to say. We really need to get a simple and
stable set of requirement for the device driver authors so they
have
Andrew Morton <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Eric W. Biederman) wrote:
>>
>> Andrew Morton <[EMAIL PROTECTED]> writes:
>>
>> > My fairly ordinary x86 test box gets stuck during reboot on the
>> > wait_for_completion() in ide_do_drive_cmd():
>>
>> Hmm. The only thing I can th
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
>
> Andrew Morton <[EMAIL PROTECTED]> writes:
>
> > My fairly ordinary x86 test box gets stuck during reboot on the
> > wait_for_completion() in ide_do_drive_cmd():
>
> Hmm. The only thing I can think of is someone started adding calls
> to device_
Andrew Morton <[EMAIL PROTECTED]> writes:
> My fairly ordinary x86 test box gets stuck during reboot on the
> wait_for_completion() in ide_do_drive_cmd():
Hmm. The only thing I can think of is someone started adding calls
to device_suspend() before device_shutdown(). Not understanding
where it w
[EMAIL PROTECTED] (Eric W. Biederman) writes:
> Andrew Morton <[EMAIL PROTECTED]> writes:
>
>> My fairly ordinary x86 test box gets stuck during reboot on the
>> wait_for_completion() in ide_do_drive_cmd():
>
> Hmm. The only thing I can think of is someone started adding calls
> to device_suspend(
My fairly ordinary x86 test box gets stuck during reboot on the
wait_for_completion() in ide_do_drive_cmd():
(gdb) thread 73
[Switching to thread 73 (Thread 2906)]#0 ide_do_drive_cmd (drive=0xc072dd10,
rq=0x0,
action=ide_wait) at drivers/ide/ide-io.c:1671
1671rq->waiti
Hi!
> The reboot code paths seems to be suffering from 15 years of people
> only looking at the code when it breaks. The result is there
> are several code paths in which different callers expect different
> semantics from the same functions, and a fair amount of imperfect
> inline replication of
The reboot code paths seems to be suffering from 15 years of people
only looking at the code when it breaks. The result is there
are several code paths in which different callers expect different
semantics from the same functions, and a fair amount of imperfect
inline replication of code.
For a
25 matches
Mail list logo
