On Thu, 2 Feb 2012 14:36:02 -0800
Matt Thomas m...@3am-software.com wrote:
kernel DSI read trap @ 0xa00011c8 by pool_cache_get_paddr+0x4c:
srr1=0x9032 r1=0xa22b9aa0 cr=0x28284084 xer=0x02000 ctr=0x1642c
dsisr=0x4000
The backtrace:
copyright
kmem_intr_alloc
On 02/02/2012 12:28 AM, Lars Heidieker wrote:
Hi,
I've just posted a patch ( http://www.netbsd.org/~para/fix.patch )
- It moves uareas and buffer cache back to the kernel_map restoring
the previous behavior. Sizing the kmem_arena is changed accordingly
(Something I stepped on while checking
I guess it's better to post this here as well:
Hi,
How does timeout of select() work for short timeouts (less than timecounter
tick period)? I am working on a serial bus protocol where the master first
sends out a data packet and then waits for a reply from a slave. Timecounter
tick is 10 ms
In article 20120203120857.ga28...@kyyhky.embedtronics.fi,
Jukka Marin jma...@embedtronics.fi wrote:
I guess it's better to post this here as well:
Hi,
How does timeout of select() work for short timeouts (less than timecounter
tick period)? I am working on a serial bus protocol where the
On Feb 3, 2012, at 5:45 PM, Emmanuel Dreyfus wrote:
Emmanuel Dreyfus m...@netbsd.org wrote:
What about adding a timeout in struct puffs_msgpark and use it for
inactive operations? Returning EAGAIN from puffs_vnop_inactive seems an
easy way to work around this deadlock.
I reply to myself.
On 02/03/2012 10:56 AM, Lars Heidieker wrote:
On 02/02/2012 12:28 AM, Lars Heidieker wrote:
Hi,
I've just posted a patch ( http://www.netbsd.org/~para/fix.patch )
- It moves uareas and buffer cache back to the kernel_map restoring
the previous behavior. Sizing the kmem_arena is changed
On Fri, Feb 3, 2012 at 6:49 PM, Eduardo Horvath e...@netbsd.org wrote:
On Fri, 3 Feb 2012, Lars Heidieker wrote:
The code for proper kmem_arena sizing:
http://www.netbsd.org/~para/kmemsizing.diff
params done for i386/amd64/sparc64/arm32
Explain this to me:
/*
- * Minimum and maximum
J. Hannken-Illjes hann...@eis.cs.tu-bs.de wrote:
So this is on 5.x ?
Yes, this is on netbsd-5
For -current the getnewvnode()-getcleanvnode() path has been replaced
with a cleaner thread so getnewvnode() always gets a new vnode. This was
done to break deadlocks like this one (most time
On Feb 3, 2012, at 7:23 PM, Emmanuel Dreyfus wrote:
J. Hannken-Illjes hann...@eis.cs.tu-bs.de wrote:
So this is on 5.x ?
Yes, this is on netbsd-5
For -current the getnewvnode()-getcleanvnode() path has been replaced
with a cleaner thread so getnewvnode() always gets a new vnode. This
J. Hannken-Illjes hann...@eis.cs.tu-bs.de wrote:
kern/vfs_vnode.c rev. 1.12 and 1.13 should be sufficient -- but it needs some
testing on netbsd-5.
kern/vfs_vnode.c does not even exist on netbsd-5, I guess it means it is
not a reasonable pullup.
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
Matt Thomas wrote:
On 02.02.12 14:36:02 you wrote:
kernel DSI read trap @ 0xa00011c8 by pool_cache_get_paddr+0x4c:
srr1=0x9032 r1=0xa22b9aa0 cr=0x28284084 xer=0x02000 ctr=0x1642c
dsisr=0x4000
The backtrace:
copyright
kmem_intr_alloc
exec_elf32_makecmds
check_exec
execve1
On Feb 3, 2012, at 8:44 PM, Emmanuel Dreyfus wrote:
J. Hannken-Illjes hann...@eis.cs.tu-bs.de wrote:
kern/vfs_vnode.c rev. 1.12 and 1.13 should be sufficient -- but it needs some
testing on netbsd-5.
kern/vfs_vnode.c does not even exist on netbsd-5, I guess it means it is
not a
Hi all,
the attached patch passes down the stack base addresses of the main
thread. This is the final kernel change required to remove the stackid
logic in libpthread. This is for use by pthread_attr_getstack as needed
e.g. by a number of programs using garbage collection.
Joerg
Index:
Can you explain this new KASSERT?
+ KASSERT(vlen = sizeof(ai));
Martin
On Fri, Feb 03, 2012 at 10:25:36PM +0100, Martin Husemann wrote:
Can you explain this new KASSERT?
+ KASSERT(vlen = sizeof(ai));
Ah, never mind - it is an array, not a pointer.
Martin
In article 20120203211937.ga25...@britannica.bec.de,
Joerg Sonnenberger jo...@britannica.bec.de wrote:
-=-=-=-=-=-
Hi all,
the attached patch passes down the stack base addresses of the main
thread. This is the final kernel change required to remove the stackid
logic in libpthread. This is for
J. Hannken-Illjes hann...@eis.cs.tu-bs.de wrote:
It is called vfs_subr.c here -- you could just try a patch.
I gave it a try, but it crashes very early, with no chance of debugging
it: console is not yet usable
NetBSD 5.1_STABLE (XEN3_DOMU_PUFFS) #370: Sat Feb 4 03:21:45 CET 2012
17 matches
Mail list logo