print CPU number when warning of hazards

Hello,

The following patch would be useful for diagnostics. Please apply.

-----------------------------------

@@ -427,9 +427,9 @@ ia64_fault (unsigned long vector, unsign
                                       ? " (RSE access)" : " (data access)") : "");
                if (code = 8) {
 # ifdef CONFIG_IA64_PRINT_HAZARDS
-                       printk("%s[%d]: possible hazard @ ip=%016lx (pr = %016lx)\n",
+                       printk("%s[%d]: possible hazard @ ip=%016lx (pr = %016lx) on CPU %d\n",
                               current->comm, current->pid, regs->cr_iip + ia64_psr(regs)->ri,
-                              regs->pr);
+                              regs->pr, smp_processor_id());
 # endif
                        return;
                }

-----------------------------------

Josh Aas
Silicon Graphics, Inc. (SGI)
Linux System Software
651-683-3068

Joshua> Hello, The following patch would be useful for diagnostics.

Why does the CPU help there? Depenency-violations are specific to code, so why would the CPU matter? Apart from that, have you actually ever seen that message show up?

	--david

The idea was that it would be useful for hardware debugging - if bad hardware tripped that code then one could see what CPU it was on. Adding the CPU number there would be trivial because a printk already exists. However, after further discussions I've decided to pursue another solution which I will probably post about later. Adding the CPU number where my patch did raises the argument of "then why not do that everywhere error conditions that could be hardward related come up?", which I don't want to do.

So, it wouldn't hurt to add the CPU number there but on my end I'm not all that interested in it any more.

No - I was was operating on the assumption that our hardware diagnostics people do see it.

Josh Aas
Silicon Graphics, Inc. (SGI)
Linux System Software
651-683-3068

Joshua> The idea was that it would be useful for hardware debugging Joshua> - if bad hardware tripped that code then one could see what Joshua> CPU it was on. Adding the CPU number there would be trivial Joshua> because a printk already exists. However, after further Joshua> discussions I've decided to pursue another solution which I Joshua> will probably post about later. Adding the CPU number where Joshua> my patch did raises the argument of "then why not do that Joshua> everywhere error conditions that could be hardward related Joshua> come up?"

Exactly.

I'll leave the code as it is, then.

Thanks,

	--david