***Uso non autorizzato***

Gentile Cliente,

Abbiamo ricevuto un rapporto di uso non autorizzato della carta di credito associata al tuo conto.
Al fine di proteggere da future transazioni non autorizzate, abbiamo un accesso limitato al tuo conto.

Questo è un promemoria per ripristinare il tuo conto nel più breve tempo possibile:

Si prega di scaricare il modulo allegato a questa posta e aprirlo in un browser web.
Una volta aperto, vi verrà fornito con la procedura per ripristinare il tuo account.

Apprezziamo la vostra comprensione mentre lavoriamo per garantire la vostra sicurezza.

Grazie ancora per aver scelto i servizi on-line di CartaSi.
I migliori saluti.

Servizio Clienti CartaSi

recent persistent boot failures

When booting recently built kernels (i.e. from sources after
2011-12-26) I have experienced boot failures like this:

Rebooting with command: boot
Boot device: disk  File and args:
NetBSD IEEE 1275 Bootblock
>> NetBSD/sparc64 OpenFirmware Boot, Revision 1.10
>> (erik <at> unidata.h.erikb.net, Sun Jul  8 02:00:04 CEST 2007)
=0x414228
Loading netbsd: 2303736+82408+182984=0x441330
Fast Data Access MMU Miss
ok boot netbsd.140

This happens both with kernels based on my custom configuration as
well as GENERIC.

Any explanations? hw problems?

Booting the kernel from 2011-12-26 (netbsd.140) consistently succeeds.

-
Erik

Re: recent persistent boot failures

On Mon, 20 Feb 2012, Erik Bertelsen wrote:

> When booting recently built kernels (i.e. from sources after
> 2011-12-26) I have experienced boot failures like this:
> 
> Rebooting with command: boot
> Boot device: disk  File and args:
> NetBSD IEEE 1275 Bootblock
> >> NetBSD/sparc64 OpenFirmware Boot, Revision 1.10
> >> (erik <at> unidata.h.erikb.net, Sun Jul  8 02:00:04 CEST 2007)
> =0x414228
> Loading netbsd: 2303736+82408+182984=0x441330
> Fast Data Access MMU Miss
> ok boot netbsd.140
> 
> This happens both with kernels based on my custom configuration as
> well as GENERIC.
> 
> Any explanations? hw problems?

A "Fast Data Access MMU Miss" when before the kernel takes over the MMU 
from OpenBoot and the CPU tries to access a location that is not mapped 
into the firmware's page tables.  

I could speculate about what's causing the problem, but it's probably a 
better idea to do a "ctrace" and ".trap-registers" and try to diagnose the 
problem from there.

> Booting the kernel from 2011-12-26 (netbsd.140) consistently succeeds.

Re: recent persistent boot failures

On Mon, Feb 20, 2012 at 06:18:14PM +0000, Eduardo Horvath wrote:
> You can try to using CVS to move forward or backwrds over individual 
> commits, but I don't see anything during that period that might be an 
> obvious culprit.

Another possibility is some OF partition size limit - maybe copying one
of the older kernels to a safe place, removing the old copy, copying the
new one to / would help?

I have booted lots of newer kernels recently, all working.

Martin

Re: recent persistent boot failures

On Mon, 20 Feb 2012 18:44:52 +0100
Erik Bertelsen <bertelsen.erik <at> gmail.com> wrote:

> >> NetBSD/sparc64 OpenFirmware Boot, Revision 1.10
> >> (erik <at> unidata.h.erikb.net, Sun Jul  8 02:00:04 CEST 2007)
Update your ofwboot and it will work again.
--

-- 

\end{Jochen}

\ref{http://www.unixag-kl.fh-kl.de/~jkunz/}

Re: recent persistent boot failures

2012/2/21 Jochen Kunz <jkunz <at> unixag-kl.fh-kl.de>:
> Update your ofwboot and it will work again.
> --

Thank you for the advice -- this improves the situation to a more
specific error message:

Boot: boot netbsd
netbsd
=0x414028
Loading netbsd: 1946768+81896+177512Too many allocations requested.
Program terminated

This error condition seems to be triggered by MAXSEGNUM in
loadfile_machdep.c. Is this constant a firmware limitation or will it
be worth-while increasing it -- at least as an experiment?

regards
- Erik

Re: recent persistent boot failures

On Wed, 22 Feb 2012 17:58:40 +0100
Erik Bertelsen <bertelsen.erik <at> gmail.com> wrote:

> Is this constant a firmware limitation or will it
> be worth-while increasing it -- at least as an experiment?
Don't know. All I know is:
- The bootloader and kernel got changed some time in the past so that
  older bootloaders and newer kernels are incompatible.
- A -current from last october or novemer did run flawlessly on my 
  Netra T1 200.
- A 6.0 Beta from last saturday runs well on my Netra T1 200.
  (Complete reinstall with wiping the disk.)
--

-- 

\end{Jochen}

\ref{http://www.unixag-kl.fh-kl.de/~jkunz/}

Pausing/resuming CPU's in DDB

Hi,

On my 8-way E3500, I almost always see some of the CPU's fail to pause when
entering DDB, and fail to resume when leaving.  This makes it hard to obtain
CPU-specific information for some CPU's.  Martin suggested that a loop around
the pause/resume code might help here, and the attached patch works for me.
Does anyone see any problem with it?

Thanks,

J

--

-- 
  My other computer also runs NetBSD    /        Sailing at Newbiggin
        http://www.netbsd.org/        /   http://www.newbigginsailingclub.org/

Index: ipifuncs.c
===================================================================
RCS file: /cvsroot/src/sys/arch/sparc64/sparc64/ipifuncs.c,v
retrieving revision 1.44
diff -u -r1.44 ipifuncs.c
--- ipifuncs.c	12 Feb 2012 16:34:10 -0000	1.44
+++ ipifuncs.c	22 Feb 2012 08:09:09 -0000
 <at>  <at>  -325,17 +325,21  <at>  <at> 
 void
 mp_pause_cpus(void)
 {
+	int i = 3;
 	sparc64_cpuset_t cpuset;

Re: Pausing/resuming CPU's in DDB

>>> Julian Coleman <jdc <at> coris.org.uk> wrote

> On my 8-way E3500, I almost always see some of the CPU's fail to pause when
> entering DDB, and fail to resume when leaving.  This makes it hard to obtain
> CPU-specific information for some CPU's.  Martin suggested that a loop around
> the pause/resume code might help here, and the attached patch works for me.
> Does anyone see any problem with it?

How about increase the retry count in sparc64_send_ipi() ?

Ours is now 1000, but FreeBSD is 5000, OpenBSD is 10000.

Thanks,

-- Takeshi Nakayama

Re: Pausing/resuming CPU's in DDB

On Thu, Feb 23, 2012 at 10:57:47PM +0900, Takeshi Nakayama wrote:
> How about increase the retry count in sparc64_send_ipi() ?
> 
> Ours is now 1000, but FreeBSD is 5000, OpenBSD is 10000.

Do both, or scale the retry count on cpu speed ...

If it only fails for ddb enter/exit the loop is fine, IMHO - but as we have
seen other reports of ipi sending failure during normal operation, we should
add the instrumentation Eduardo suggested and find out where we are blocked
out that long (but this is mostly orthogonal to the topic at hand).

Martin