Check to see if there actually is data from a previously
crashed kernel waiting. If so, Allow user-sapce tools to
grab the data (by reading /proc/kcore). When user-space
finishes dumping a section, it must release that memory
by writing to sysfs. For example,
echo "0x4000 0x1000" > /sy
On 11/03/2008, Paul Mackerras <[EMAIL PROTECTED]> wrote:
>
> > --
>
> This line needs to be exactly 3 dashes, because otherwise the tools
> include the diffstat into the commit message. Putting 4 or more
> dashes was an annoying habit Linas had, and it means I have to fix it
> manually (us
Paul wrote:
> Manish Ahuja writes:
> > + dump_header = of_get_property(rtas, "ibm,kernel-dump",
> > + &header_len);
>
> This is a somewhat weird-looking way of coping with too-long lines.
Yes, but not too surprising, since it pre
Manish Ahuja writes:
> Check to see if there actually is data from a previously
> crashed kernel waiting. If so, Allow user-sapce tools to
> grab the data (by reading /proc/kcore). When user-space
> finishes dumping a section, it must release that memory
> by writing to sysfs. For example,
>
>
Check to see if there actually is data from a previously
crashed kernel waiting. If so, Allow user-sapce tools to
grab the data (by reading /proc/kcore). When user-space
finishes dumping a section, it must release that memory
by writing to sysfs. For example,
echo "0x4000 0x1000" > /sy
Check to see if there actually is data from a previously
crashed kernel waiting. If so, Allow user-sapce tools to
grab the data (by reading /proc/kcore). When user-space
finishes dumping a section, it must release that memory
by writing to sysfs. For example,
echo "0x4000 0x1000" > /s
On Fri, Feb 15, 2008 at 01:17:16AM -0600, Manish Ahuja wrote:
> Tony Breeds wrote:
> > Any reason this sysfs attribute can't be write only? The show method
> > doesn't seem needed.
>
> yes, its used later in the code.
I see that now, thanks. From my point of view it would make reviewing
these p
On 14/02/2008, Tony Breeds <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 12, 2008 at 01:11:58AM -0600, Manish Ahuja wrote:
> > +static ssize_t
> > +show_release_region(struct kset * kset, char *buf)
> > +{
> > + return sprintf(buf, "ola\n");
> > +}
> > +
> > +static struct subsys_attribute r
Tony Breeds wrote:
> On Tue, Feb 12, 2008 at 01:11:58AM -0600, Manish Ahuja wrote:
>
>
>
>> +static ssize_t
>> +show_release_region(struct kset * kset, char *buf)
>> +{
>> +return sprintf(buf, "ola\n");
>> +}
>> +
>> +static struct subsys_attribute rr = __ATTR(release_region, 0600,
>> +
On Tue, Feb 12, 2008 at 01:11:58AM -0600, Manish Ahuja wrote:
> +static ssize_t
> +show_release_region(struct kset * kset, char *buf)
> +{
> + return sprintf(buf, "ola\n");
> +}
> +
> +static struct subsys_attribute rr = __ATTR(release_region, 0600,
> + s
As noted, its fixed in patch 4.
If its okay for this time, I will prefer to leave it there.
-Manish
Stephen Rothwell wrote:
> Hi Manish,
>
> Just a small comment.
>
> On Tue, 12 Feb 2008 01:11:58 -0600 Manish Ahuja <[EMAIL PROTECTED]> wrote:
>> +/* Is there dump data waiting for us? */
>
Hi Manish,
Just a small comment.
On Tue, 12 Feb 2008 01:11:58 -0600 Manish Ahuja <[EMAIL PROTECTED]> wrote:
>
> + /* Is there dump data waiting for us? */
> + rtas = of_find_node_by_path("/rtas");
> + dump_header = of_get_property(rtas, "ibm,kernel-dump", &header_len);
You need an of
Check to see if there actually is data from a previously
crashed kernel waiting. If so, Allow user-space tools to
grab the data (by reading /proc/kcore). When user-space
finishes dumping a section, it must release that memory
by writing to sysfs. For example,
echo "0x4000 0x1000" > /sy
Check to see if there actually is data from a previously
crashed kernel waiting. If so, Allow user-sapce tools to
grab the data (by reading /proc/kcore). When user-space
finishes dumping a section, it must release that memory
by writing to sysfs. For example,
echo "0x4000 0x1000" > /sy
14 matches
Mail list logo
