headers
Jasper Wallace | 11 Apr 2011 01:50
Favicon

kgdb status?


Is kgdb known to be working in -current atm? it panics for me.

--

-- 
[http://pointless.net/]                                   [0x2ECA0975]
Permalink | Reply | 0 comments |
headers
Jonathan A. Kollasch | 12 Apr 2011 03:17
Gravatar

sometimes resumeable freeze

Hi,

My quad core AMD box has an issue where it will lock up under load.

Often, when the machine is otherwise unresponsive, I'll press
Num Lock on the pckbd(4) and it will awaken at the point in time
it went comatose.  Eventually, pressing num lock doesn't bring it
back and I have to force a reboot.

If I `cpuctl offline` ¾ of the CPUs the machine is acceptably stable.
The machine is also acceptably stable under Linux with all cores
enabled and performing a similar workload (build.sh release).

acpicpu(4) is present in the kernel and I have verified that C1E
is not enabled.  The machine was significantly less stable when
C1E was enabled.

I've tried to wire in a Conventional PCI SERR# trigger, but
the chipset doesn't propagate that into an NMI and I lack
details on the chipset required to enable that if possible.

Can anyone think of ways to debug this issue?

	Jonathan Kollasch
Permalink | Reply | 2 comments |
headers
Jonathan A. Kollasch | 13 Apr 2011 20:18
Gravatar

Re: sometimes resumeable freeze

On Tue, Apr 12, 2011 at 01:17:32AM +0000, Jonathan A. Kollasch wrote:
> I've tried to wire in a Conventional PCI SERR# trigger, but
> the chipset doesn't propagate that into an NMI and I lack
> details on the chipset required to enable that if possible.

With a little help, I managed to enable NMI on SERR#.
Machine will drop to DDB on NMI while it's hung.

Now, to decipher the backtraces.

	Jonathan Kollasch
Permalink | Reply | 0 comments |
headers
Iain Hibbert | 19 Apr 2011 12:49

Re: GNU vs C99 extern inline

On Sun, 17 Apr 2011, Joerg Sonnenberger wrote:

> On Sat, Apr 16, 2011 at 09:27:41PM +0100, Iain Hibbert wrote:
> > returning to GNUC vs C99 semantics for inline functions, this is now
> > partly handled with a __c99inline keyword but there are several files in
> > the kernel containing functions marked inline that yet require external
> > linkage as they are also called from other source modules..  this is
> > provided by the opposite of __c99inline in both the GNUC and C99 cases, as
> > per the patch below which adds an __extinline keyword for this usage
>
> Please don't add anything like this, but fix the corresponding users. It
> is not even sure if such use is correct under C99 use.

here is the first; x86 is the only pmap.c that provides an inline
attribute for pmap_reference().. options include just removing it, which
only affects calls from inside pmap.c (eg none of the uvm code gets the
inline benefit anyway) or the patch below replaces pmap_reference() with a
macro so that it is effectively always inlined..

any objections from x86 ports?

iain

Index: include/pmap.h
===================================================================
RCS file: /cvsroot/src/sys/arch/x86/include/pmap.h,v
retrieving revision 1.35
diff -u -r1.35 pmap.h
--- include/pmap.h	11 Feb 2011 23:08:38 -0000	1.35
+++ include/pmap.h	19 Apr 2011 10:38:23 -0000
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mindaugas Rasiukevicius | 20 Apr 2011 15:43
Picon

Re: GNU vs C99 extern inline

Iain Hibbert <plunky <at> rya-online.net> wrote:
> Index: x86/pmap.c
> ===================================================================
> RCS file: /cvsroot/src/sys/arch/x86/x86/pmap.c,v
> retrieving revision 1.118
> diff -u -r1.118 pmap.c
> --- x86/pmap.c	11 Feb 2011 23:08:38 -0000	1.118
> +++ x86/pmap.c	19 Apr 2011 10:38:26 -0000
>  <at>  <at>  -764,17 +764,6  <at>  <at> 
>  }
> 
>  /*
> - *	Add a reference to the specified pmap.
> - */
> -
> -inline void
> -pmap_reference(struct pmap *pmap)
> -{
> -
> -	atomic_inc_uint(&pmap->pm_obj[0].uo_refs);
> -}
> -
> -/*
>   * pmap_map_ptes: map a pmap's PTEs into KVM and lock them in
>   *
>   * => we lock enough pmaps to keep things locked in

Not worth.  Please just drop inline and leave as a function.

Thanks.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christoph Egger | 27 Apr 2011 07:26
Picon
Picon

Re: Motherboard chipset for NetBSD 5.1


I have to apologize for resending those old mails.

K9 on my android phone had "outgoing" and "sent" folders
configured to the same folder causing K9 to keep
sending old mails silently.

Sorry for any inconviniences,
Christoph

On 30.11.10 09:21, Christoph Egger wrote:
> 
> The board is not the problem. If you have trouble with
> booting NetBSD SMP then you might be affected by the C1E errata.
> A workaround has been applied to -current today.
> It should be applied to NetBSD 5.1, too.
> 
> W/o the workaround you should be able to boot NetBSD with ACPI
> and w/o SMP at least.
> 
> Christoph
> 
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>>
>> On 11/27/10 10:13 AM, Morten Gulbrandsen (Java programmer) wrote:
>>> Hello,
>>>
>>> I have this motherboard in my mind:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rui-Xiang Guo | 28 Apr 2011 06:01
Picon

chromium 10

Hi, all.
I have updated wip/chromium to 10.0.648.205 and tested it on both NetBSD-5.1
amd64 & i386. The test on amd64 seems more unstable than i386. You may type
this command - "# ulimit -Sn 400" or "% limit descriptors 400" depends on
your shell if you get a crash frequently. Please test it and report,
especially on DragonFly, thanks.

-rxg
Permalink | Reply | 0 comments |

Gmane