Re: Weird PUFFS reclaim activity on netbsd-6
On Thu, Mar 08, 2012 at 05:32:47AM +0100, Emmanuel Dreyfus wrote: A posible explanation: perfuse tries to reuse nodes. If the same node is looked up twice and not reclaimed in between, perfuse return the same node Further experiments suggest this is the problem. netbsd-6 can lookup multiple time the same node without sending a reclaim. But at the end, there will be as many reclaims as lookups. If perfuse tracks the lookup/reclaim counts and ignore reclaims until it gets to zero, things seems to work fine. But this new behavior does not seems very smart on the performance front. The kernel sends a lookup for a nodes it already knows, and it sends reclaims that must be ignored. In the context of PUFFS filesystem, unnecessary VFS ops has a real cost. Is there some rationale behind this change? -- Emmanuel Dreyfus m...@netbsd.org
Re: Recent 6.0_BETA crash
I few minutes ago I updated the kernel and modules on my 6.0_BETA to the latest netbsd-6 sources and enabled debugging kernel options. optionsDEBUG # expensive debugging checks/support makeoptionsDEBUG=-g # compile full symbol table Userlevel was not updated. After login in xdm the system crashed. at /srv/src_netbsd_current/sys/arch/x86/x86/pmap.c:3326 3326KASSERT(uvm_page_locked_p(pg)); Stacktrace is below. Any clue? It looks like the same problem as what makes the kernel occasionally panic while running tests. It looks like a race condition causing memory corrution, but this is hard to track down ... On my system this crash is reproducible. At least it repeated three times with xdm login. Does it make sense to send PR? -- Best regards, Aleksey Cheusov.
Re: Recent 6.0_BETA crash
On Thu, Mar 08, 2012 at 02:04:49PM +0300, Aleksey Cheusov wrote: I few minutes ago I updated the kernel and modules on my 6.0_BETA to the latest netbsd-6 sources and enabled debugging kernel options. optionsDEBUG # expensive debugging checks/support makeoptionsDEBUG=-g # compile full symbol table Userlevel was not updated. After login in xdm the system crashed. at /srv/src_netbsd_current/sys/arch/x86/x86/pmap.c:3326 3326KASSERT(uvm_page_locked_p(pg)); Stacktrace is below. Any clue? It looks like the same problem as what makes the kernel occasionally panic while running tests. It looks like a race condition causing memory corrution, but this is hard to track down ... On my system this crash is reproducible. At least it repeated three times with xdm login. Does it make sense to send PR? Does it always fail in the same way, or does the panic happen at random places ? -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Enable KMEM_GUARD without all the rest of DEBUG ?
On another thread discussing random kernel crashes (likely due to memory corruption) [1], it was suggested that KMEM_GUARD might be a useful tool for debugging... By adding KMEM_GUARD itself to a kernel config file, I discovered that KMEM_GUARD cannot be enabled individually - it is currently required as part of a set of tools that are collectively enabled by 'options DEBUG' /build/netbsd-test/src/sys/kern/subr_kmem.c: In function 'kmem_init': /build/netbsd-test/src/sys/kern/subr_kmem.c:344:20: error: 'kmem_guard' undeclared (first use in this function) /build/netbsd-test/src/sys/kern/subr_kmem.c:344:33: error: 'kmem_guard_depth' undeclared (first use in this function) /build/netbsd-test/src/sys/kern/subr_kmem.c:344:52: error: 'kmem_guard_size' undeclared (first use in this function) The following patches allow building of a kernel with only KMEM_GUARD. The first patch makes the variable allocations depend on the KMEM_GUARD whether or not DEBUG was specified, and the second patch includes the necessary uvm_kmguard.c when either option is specified. Index: subr_kmem.c === RCS file: /cvsroot/src/sys/kern/subr_kmem.c,v retrieving revision 1.42 diff -u -p -r1.42 subr_kmem.c --- sys/kern/subr_kmem.c 5 Feb 2012 03:40:08 - 1.42 +++ sys/kern/subr_kmem.c 8 Mar 2012 01:53:32 - @@ -122,9 +122,6 @@ static pool_cache_t kmem_cache[KMEM_CACH static size_t kmem_cache_maxidx __read_mostly; #if defined(DEBUG) -int kmem_guard_depth = 0; -size_t kmem_guard_size; -static struct uvm_kmguard kmem_guard; static void *kmem_freecheck; #defineKMEM_POISON #defineKMEM_REDZONE @@ -132,6 +129,12 @@ static void *kmem_freecheck; #defineKMEM_GUARD #endif /* defined(DEBUG) */ +#if defined (KMEM_GUARD) +int kmem_guard_depth = 0; +size_t kmem_guard_size; +static struct uvm_kmguard kmem_guard; +#endif + #if defined(KMEM_POISON) static int kmem_poison_ctor(void *, void *, int); static void kmem_poison_fill(void *, size_t); Index: uvm/files.uvm === RCS file: /cvsroot/src/sys/uvm/files.uvm,v retrieving revision 1.20 diff -u -p -r1.20 files.uvm --- sys/uvm/files.uvm 17 May 2011 05:32:31 - 1.20 +++ sys/uvm/files.uvm 8 Mar 2012 02:18:55 - @@ -25,7 +25,7 @@ file uvm/uvm_glue.c file uvm/uvm_init.c file uvm/uvm_io.c file uvm/uvm_km.c -file uvm/uvm_kmguard.c debug +file uvm/uvm_kmguard.c debug | kmem_guard file uvm/uvm_loan.c file uvm/uvm_map.c file uvm/uvm_meter.c Does anyone have any objections to committing these fixes? [1] http://mail-index.netbsd.org/current-users/2012/03/07/msg019419.html - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: posix_spawn() bug ? [Re: try KMGUARD]
On Thu, Mar 08, 2012 at 04:00:05PM +0100, Martin Husemann wrote: On Thu, Mar 08, 2012 at 03:51:05PM +0100, Manuel Bouyer wrote: pmap_deactivate() at netbsd:pmap_deactivate+0x93 mi_switch() at netbsd:mi_switch+0x2c5 kpreempt() at netbsd:kpreempt+0xe2 Xpreemptrecurse() at netbsd:Xpreemptrecurse+0x15 spawn_return() at netbsd:spawn_return+0x1f8 [..] l is fe81b139ac00, l-l_proc is fe81adc422a0, l-l_proc-p_vmspace is NULL. Yes, this is the case for the early child process untill everything is ready. It should not be preematable there... I'll have a look (I'm reworking parts of this anyway). Does this bug also exist in netbsd-6 ? -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: posix_spawn() bug ? [Re: try KMGUARD]
On Thu, Mar 08, 2012 at 04:13:41PM +0100, Martin Husemann wrote: On Thu, Mar 08, 2012 at 04:07:19PM +0100, Manuel Bouyer wrote: Does this bug also exist in netbsd-6 ? Yes. OK, I opened kern/46153 so releng can track it. -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: Problem with install of NetBSD-6 from cd on i386 siside
On 7 Mar 2012 at 23:25, David Lord wrote: On 7 Mar 2012 at 16:24, Manuel Bouyer wrote: On Wed, Mar 07, 2012 at 03:14:52PM -, David Lord wrote: Hi I've tried without success to install NetBSD-6 from CD from a downloaded iso image onto an i386 system. The error is: cd0(siside0:1:0): Check Condition on CDB: 0x28 00 00 00 a6 0d 00 00 04 00 SENSE KEY: Media Error INFO FIELD: 42509 ASC/ASCQ: No Seek Complete I had same problem with 6.99 I have since obtained netbsd-6 src via cvs on a different system, built a release, copied sets over network and updated target pc to NetBSD-6. I am able to mount the cdrom and tar -tzvf comp.tgz initially gave same error as above but then completed ok. Seems the drive isn't being allowed to spin up. I don't think that's the problem. A media error is really what it says: the drive coudln't read some data on the drive. If you've been able to mount it, then at last you can read some data out of it. So it's just some parts of the media which are bad. I've now found same errors from ubuntu so will invest in a replacement drive and pack of fresh cds. I've just created my own iso image from the NetBSD-6 releas built from source. This was burned to cdrom using cdrecord and then copied back to hard disk without a single error from the suspect cdrom drive. I'm now suspecting that downloads of both of the two iso images I tried were corrupted. David
Re: SSD trim support
da...@l8s.co.uk said: Do any CF cards actually support 'erase' I've got a couple of CF cards which announce the CFA command extension and thus should support it. Two cards don't announce it -- a very old 512MB one and a 1G IBM Microdrive. For the latter it wouldn't make much sense obviously. best regards Matthias --- --- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt --- --- Kennen Sie schon unsere app? http://www.fz-juelich.de/app
