On Fri, 2012-04-27 at 19:02 -0500, Larry Finger wrote:
> It is a 15" Powerbook G4. I think they call it a Titanium. The console is not
> on
> a serial port. In fact, the reason that I did not think this patch was a
> problem
> is because the serial port does not appear to be connected to an ex
On 04/27/2012 05:26 PM, Benjamin Herrenschmidt wrote:
On Fri, 2012-04-27 at 10:38 -0500, Larry Finger wrote:
Sorry, I was unable to find anything in debugfs to help me learn about interrupt
mapping. The value of CONFIG_NR_IRQS is already 512. I have not tried reducing
it to 128. The setting for
On Fri, 2012-04-27 at 10:38 -0500, Larry Finger wrote:
> Sorry, I was unable to find anything in debugfs to help me learn about
> interrupt
> mapping. The value of CONFIG_NR_IRQS is already 512. I have not tried
> reducing
> it to 128. The setting for CONFIG_SPARSE_IRQ was on, and changing it
Em 27-04-2012 15:11, Luck, Tony escreveu:
+ for (i = 0; i < dimm->mci->n_layers; i++) {
+ printk(KERN_CONT "%d", dimm->location[i]);
+ if (i < dimm->mci->n_layers - 1)
+ printk(KERN_CONT ".");
+ }
+ printk(KERN_CONT "\n");
>>>
>>>
>>> + for (i = 0; i < dimm->mci->n_layers; i++) {
>>> + printk(KERN_CONT "%d", dimm->location[i]);
>>> + if (i < dimm->mci->n_layers - 1)
>>> + printk(KERN_CONT ".");
>>> + }
>>> + printk(KERN_CONT "\n");
>>
>> This looks hacky but I don't have a good su
Em 27-04-2012 11:11, Joe Perches escreveu:
> On Fri, 2012-04-27 at 15:33 +0200, Borislav Petkov wrote:
>> this patch gives
>>
>> [8.278399] EDAC DEBUG: new_edac_mc_alloc: new_edac_mc_alloc: 0: dimm0
>> (0:0:0): row 0, chan 0
>
> One too many __func__'s in some combination of the
> pr_fmt and/
On 04/25/2012 04:44 PM, Benjamin Herrenschmidt wrote:
Do we know what the bad interrupt maps to ? Also what is the value of
NR_IRQ and do you have SPARSE_IRQ enabled ? Can you try with the latter
disabled and NR_IRQ set to something large, such as 128 ?
(You may be able to check the interrupt m
Em 27-04-2012 10:33, Borislav Petkov escreveu:
> Btw,
>
> this patch gives
>
> [8.278399] EDAC DEBUG: new_edac_mc_alloc: new_edac_mc_alloc: 0: dimm0
> (0:0:0): row 0, chan 0
> [8.287594] EDAC DEBUG: new_edac_mc_alloc: new_edac_mc_alloc: 1: dimm1
> (0:1:0): row 0, chan 1
> [8.296784]
On Fri, Apr 27, 2012 at 10:11:35AM -0400, Joe Perches wrote:
> > > -extern struct mem_ctl_info *edac_mc_alloc(unsigned sz_pvt, unsigned
> > > nr_csrows,
> > > - unsigned nr_chans, int edac_index);
> > > +struct mem_ctl_info *edac_mc_alloc(unsigned sz_pvt, unsigned
On Fri, 2012-04-27 at 15:33 +0200, Borislav Petkov wrote:
> this patch gives
>
> [8.278399] EDAC DEBUG: new_edac_mc_alloc: new_edac_mc_alloc: 0: dimm0
> (0:0:0): row 0, chan 0
One too many __func__'s in some combination of the
pr_fmt and/or dbg call and/or the actual call site?
> > diff --g
Btw,
this patch gives
[8.278399] EDAC DEBUG: new_edac_mc_alloc: new_edac_mc_alloc: 0: dimm0
(0:0:0): row 0, chan 0
[8.287594] EDAC DEBUG: new_edac_mc_alloc: new_edac_mc_alloc: 1: dimm1
(0:1:0): row 0, chan 1
[8.296784] EDAC DEBUG: new_edac_mc_alloc: new_edac_mc_alloc: 2: dimm2
(1:0
Benjamin Herrenschmidt writes:
> Ok, I'll switch that back then. It seemed more sensible to read the
> actual fan values rather than the programmed ones (in fact I wonder if I
> can just skip the read alltogether then and use a cached value but that
> means I won't be able to detect failed fans..
12 matches
Mail list logo
