config(8) dumps core

2010-04-29 Thread Michael Moll
Hi All, after upgrading a FreeBSD/sparc64 machine from CURRENT sources of 3rd March to ones of 28th April config(8) doesn't work correctly anymore: server01# config -x /boot/kernel/kernel options CONFIG_AUTOGENERATED ident GENERIC machine sparc64 cpu SUN4U [...] device fwe device fwip

Re: config(8) dumps core

2010-04-29 Thread Andriy Gapon
on 29/04/2010 18:31 Michael Moll said the following: [snip] Assertion failed: (r != '\0' (Char present in the configuration string mustn't be equal to 0)), function kernconfdump, file /usr/src/usr.sbin/config/main.c, line 721. [snip] Any ideas on this? Yes, one idea - to verify what the

Re: config(8) dumps core

2010-04-29 Thread Andriy Gapon
on 30/04/2010 00:12 Michael Moll said the following: Hi, On Thu, Apr 29, 2010 at 11:33:30PM +0300, Andriy Gapon wrote: on 29/04/2010 18:31 Michael Moll said the following: You can use hd to see if you indeed have '\0' (0x00) symbol somewhere within your kernel config file. Thanks, I

Re: config(8) dumps core

2010-04-29 Thread Michael Moll
Hi, On Thu, Apr 29, 2010 at 11:33:30PM +0300, Andriy Gapon wrote: on 29/04/2010 18:31 Michael Moll said the following: You can use hd to see if you indeed have '\0' (0x00) symbol somewhere within your kernel config file. Thanks, I checked this and there are no 0x00s in the config file itself,

Re: config(8) dumps core

2010-04-29 Thread Bruce Cran
On Thursday 29 April 2010 22:19:45 Andriy Gapon wrote: on 30/04/2010 00:12 Michael Moll said the following: Hi, On Thu, Apr 29, 2010 at 11:33:30PM +0300, Andriy Gapon wrote: on 29/04/2010 18:31 Michael Moll said the following: You can use hd to see if you indeed have '\0' (0x00) symbol

Re: config(8) dumps core

2010-04-29 Thread Garrett Cooper
On Thu, Apr 29, 2010 at 2:41 PM, Bruce Cran br...@cran.org.uk wrote: On Thursday 29 April 2010 22:19:45 Andriy Gapon wrote: on 30/04/2010 00:12 Michael Moll said the following: Hi, On Thu, Apr 29, 2010 at 11:33:30PM +0300, Andriy Gapon wrote: on 29/04/2010 18:31 Michael Moll said the

Re: config(8) dumps core

2010-04-29 Thread Bruce Cran
On Thursday 29 April 2010 22:46:29 Garrett Cooper wrote: Does a version prior to last week work, and could you please attach your kernel configuration file(s) for analysis? I remember coming across the same error during buildkernel last week, but can't remember how, or how I resolved it.

Re: config(8) dumps core

2010-04-29 Thread Michael Moll
Hi, On Thu, Apr 29, 2010 at 11:30:06PM +0100, Bruce Cran wrote: /boot/kernel/kernel. It looks like it thinks there's more data available than there is. config/main.c gets the size of the configuration by running elfdump: elfdump -c /boot/kernel/kernel | grep -A 5 kern_conf | tail -2 |

Re: config(8) dumps core

2010-04-29 Thread M. Warner Losh
In message: 20100429224938.gi90...@darkthrone.kvedulv.de Michael Moll kved...@kvedulv.de writes: : Hi, : : On Thu, Apr 29, 2010 at 11:30:06PM +0100, Bruce Cran wrote: : /boot/kernel/kernel. It looks like it thinks there's more data available : than there is. : : config/main.c

Re: config(8) dumps core

2010-04-29 Thread Michael Moll
On Thu, Apr 29, 2010 at 05:07:00PM -0600, M. Warner Losh wrote: Do you have a small, reproducible sequence of events that will recreate this problem? I've seen no problems at all in my testing. I assume this is in -current? Yes, -CURRENT. Compile a kernel on sparc64 (didn't try this yet on

Re: config(8) dumps core

2010-04-29 Thread M. Warner Losh
In message: 2010043016.ga90...@darkthrone.kvedulv.de Michael Moll kved...@kvedulv.de writes: : On Thu, Apr 29, 2010 at 05:07:00PM -0600, M. Warner Losh wrote: : Do you have a small, reproducible sequence of events that will : recreate this problem? I've seen no problems at all

Re: config(8) dumps core

2010-04-29 Thread Bruce Cran
On Thursday 29 April 2010 23:49:38 Michael Moll wrote: OK, that explains that with all the related commits backup out (207265-206664) the resulting config-binary still fails. I don't have time today to build the kernel with the different revisions to hunt the problem down to one commit...