Re: kmem change related trouble

2012-02-03 Thread Frank Wille
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

Re: kmem change related trouble

2012-02-03 Thread Lars Heidieker
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

select() timeout

2012-02-03 Thread Jukka Marin
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

Re: select() timeout

2012-02-03 Thread Christos Zoulas
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

Re: PUFFS deadlock

2012-02-03 Thread J. Hannken-Illjes
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.

Re: kmem change related trouble

2012-02-03 Thread Lars Heidieker
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

Re: kmem change related trouble

2012-02-03 Thread Lars Heidieker
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

Re: PUFFS deadlock

2012-02-03 Thread Emmanuel Dreyfus
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

Re: PUFFS deadlock

2012-02-03 Thread J. Hannken-Illjes
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

Re: PUFFS deadlock

2012-02-03 Thread Emmanuel Dreyfus
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

Re: kmem change related trouble

2012-02-03 Thread Frank Wille
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

Re: PUFFS deadlock

2012-02-03 Thread J. Hannken-Illjes
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

Support for passing down the stack base to userland

2012-02-03 Thread Joerg Sonnenberger
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:

Re: Support for passing down the stack base to userland

2012-02-03 Thread Martin Husemann
Can you explain this new KASSERT? + KASSERT(vlen = sizeof(ai)); Martin

Re: Support for passing down the stack base to userland

2012-02-03 Thread Martin Husemann
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

Re: Support for passing down the stack base to userland

2012-02-03 Thread Christos Zoulas
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

Re: PUFFS deadlock

2012-02-03 Thread Emmanuel Dreyfus
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