lkml.org 
[lkml]   [2005]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] PPC64: EEH Recovery
Linas Vepstas writes:

> > 2. I don't see why the device nodes for the PCI subtree being reset
> > would go away, and thus I don't see the need for your eeh_cfg_tree
> > struct.
>
> Its not the reset, its the hot-plug remove. The hot plug code assumes
> that you are going to physically remove the device from the slot, so
> it removes the device_node as part of the "unconfig".

OK, I missed that. It seems a bit bogus to me. Could you point me at
where in the code this happens?

> > 3. Is there a good reason why we can't use the assigned-addresses
> > property on the relevant device tree nodes to tell us what to set
> > the BARs to?
>
> Yes, the reason is that after a reset, that property doesn't hold any
> decent data. I discussed this with the firmware developers, and thier
> response was that it is the kernel's responsibility to compute
> (or save/restore) such values. (Except for bridges, which they will do for us).

The not holding any decent data is a consequence of the device nodes
getting thrown away, isn't it? I fail to see how resetting the device
can of itself affect our copy of the device tree.

> > In particular I think it should be a
> > userland write to a sysfs file that kicks off the restart process
> > rather than it just happening after 5 seconds. Anyway, what
> > process or thread is executing that 5 second sleep? Is it keventd
> > or something?
>
> Its a workqueue.

Which get run in keventd's context. In other words no other
workqueues will get run during the 5 second sleep, or at least not on
that cpu.

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

\
 
 \ /
  Last update: 2005-03-22 14:09    [W:2.096 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site