On 10/25/18 2:14 AM, Marcin Cieslak wrote:
> On Wed, 24 Oct 2018, John Baldwin wrote:
>
>> On 10/23/18 10:58 AM, Marcin Cieslak wrote:
>>> This GDB was configured as "amd64-marcel-freebsd"...BFD:
>>> /boot/kernel/kernel: invalid relocation type 37
>>> BFD: BFD 2.17.50 [FreeBSD] 2007-07-03 asserti
On Wed, 24 Oct 2018, John Baldwin wrote:
> On 10/23/18 10:58 AM, Marcin Cieslak wrote:
> > This GDB was configured as "amd64-marcel-freebsd"...BFD:
> > /boot/kernel/kernel: invalid relocation type 37
> > BFD: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail
> > /usr/src/gnu/usr.bin/binutils/libbf
On 10/23/18 10:58 AM, Marcin Cieslak wrote:
> Hello, I have a freshly built 12.0-ALPHA10 (r339406) and the kernel
> panicked at some point (another mail coming on that).
>
> I have a full dump partition enabled, but during savecore
> quite lot BFD assertion messages appear:
>
> Tue Oct 23 18:45:5
- Original Message -
From: "Doug White" <[EMAIL PROTECTED]>
To: "Jaco H. van Tonder" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: 07/11/2003 11:28 PM
Subject: Re: savecore changed?
> On Fri, 7 Nov 2003, Jaco H. van Tonder wrote:
>
> &
On Fri, 7 Nov 2003, Jaco H. van Tonder wrote:
> Doug,
>
> Sorry, my bad, there was no dump availible. I still dont know how I
> would manage to get a dump if the kernel panics while busy booting (It
> does not know about dumpdev yet?)
Ouch. Yeah this is one of those times when you can't grab a du
. van Tonder" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: 07/11/2003 3:06 AM
Subject: Re: savecore changed?
> On Thu, 6 Nov 2003, Jaco H. van Tonder wrote:
>
> > Hi all,
> >
> > I have a -CURRENT kernel that panics the moment it starts booting, and I
On Thu, 6 Nov 2003, Jaco H. van Tonder wrote:
> Hi all,
>
> I have a -CURRENT kernel that panics the moment it starts booting, and I
> have to use another kernel to boot properly (GENERIC). The problem is that I
> want to dump the core from the faulty kernel, and I see that savecore no
> longer su
On Wed, Oct 08, 2003 at 07:05:49PM -0700, Doug White wrote:
> > > The ROSB4 is known to have data-corruption problems with running in UDMA
> > > mode. The dump is probably tripping over this, which is why Tor's patch
> > > works since it demotes the device back to PIO.
> >
> > I also had problems
On Tue, 7 Oct 2003, Kris Kennaway wrote:
> On Tue, Oct 07, 2003 at 06:11:30PM -0700, Doug White wrote:
> > On Tue, 7 Oct 2003, YONETANI Tomokazu wrote:
> >
> > > The hardware is IBM NetFinity 6000R, and it has ServerWorks ROSB4 UDMA33
> > > controller, to which the IDE disk is attached. The size o
On 2003/10/07 18:11:30, Doug White wrote:
> On Tue, 7 Oct 2003, YONETANI Tomokazu wrote:
>
> > The hardware is IBM NetFinity 6000R, and it has ServerWorks ROSB4 UDMA33
> > controller, to which the IDE disk is attached. The size of the IDE hard
> > disk is 4Gbytes, and the size of the kernel dump a
On Tue, 7 Oct 2003, Kris Kennaway wrote:
> I also had problems dumping onto a UDMA66 disk on a promise PDC20267
> controller - it seemed to dump OK (dump was readable after I recovered
> the disk), but it (or maybe the crash itself) trashed the partition
> table.
>
> Kris
I mentioned the very sa
On Tue, Oct 07, 2003 at 06:11:30PM -0700, Doug White wrote:
> On Tue, 7 Oct 2003, YONETANI Tomokazu wrote:
>
> > The hardware is IBM NetFinity 6000R, and it has ServerWorks ROSB4 UDMA33
> > controller, to which the IDE disk is attached. The size of the IDE hard
> > disk is 4Gbytes, and the size of
On Tue, 7 Oct 2003, YONETANI Tomokazu wrote:
> The hardware is IBM NetFinity 6000R, and it has ServerWorks ROSB4 UDMA33
> controller, to which the IDE disk is attached. The size of the IDE hard
> disk is 4Gbytes, and the size of the kernel dump and physical memory both
> fits in that size.
The RO
> Hello.
> -CURRENT as of yesterday can't save kernel dump:
>
> savecore: first and last dump headers disagree on /dev/ad0b
> savecore: unsaved dumps found but not saved
>
> Is this a known issue?
Yes.
I had the same problem on my development machine at the end of August and
ended up usin
On Mon, Jul 28, 2003 at 08:24:12AM -0400, David Hill wrote:
> Hello -
> savecore and its manpage are missing options.
>
> savecore is missing -z and -N from its usage list.
> savecore manpage is missing -N.
-z is missing, but -N is obsolete and simply results in a usage()
message.
Does anyone ob
Yes, I'm in favor of going back to the simple sequence number too.
I don't understand the advantage of the MD5.
While you're in there, could you put back minfree checking too?
That bit me pretty badly today, with savecore filling up my /var
because it doesn't care about minfree.
Bill
To Unsub
On 2002-04-19 21:00, Chad David wrote:
> I was actually hoping for a few more comments on the code, but thanks
> anyway ;).
Nah... Most of the code looks OK, as far as I can tell. I'm not a C
guru or something similar, but it is fine. Style things like the two
below were what I had written abo
On Sat, Apr 20, 2002 at 03:28:18AM +0300, Giorgos Keramidas wrote:
> On 2002-04-19 00:31, Chad David wrote:
> > Any comments / objections to these patches to savecore and friends?
>
> Since you asked ... :)
Yes, I did.
>
> > Index: savecore.8
> > ===
On 2002-04-19 00:31, Chad David wrote:
> Any comments / objections to these patches to savecore and friends?
Since you asked ... :)
> Index: savecore.8
> ===
> +The
> +.Nm savecore
You can safely remove "savecore" from the .Nm arg
* Chad David <[EMAIL PROTECTED]> [020418 23:32] wrote:
> Any comments / objections to these patches to savecore and friends?
>
> After I get more than two or three md5 named files in var/crash I
> start to go cross eyed.
I found the md5 names to be particularly disgusting as well. If this
rever
On Sun, Apr 07, 2002 at 02:37:23PM -0700, Steven G. Kargl wrote:
> The recent changes to savecore/dumpsys are generating
> the following message at boot:
>
> Checking for core dump: Mediasize = 373293056
> Sectorsize = 512
> savecore: Parity error on last dump header on /dev/da0s2b
>
How does o
Should be fixed.
> Savecore isn't working in -current, dying in my case with "read:
> invalid argument". (This is on an Alpha -- I don't have an i386
> -current machine to test it on at the moment.) I traced it down to
> the fact that getbootfile() is returning "kernel" -- not the full
> path
>
> Though the alpha code (alpha/libalpha/bootinfo.c) also fill in a lot of
> stuff in bi, it has no reference at all to "kernelname". Did it ever
> work? :-)
>
Hmm. Maybe not. I'd convinced myself that the loader is currently just
passing "kernel" either as an environmental variable or in boo
Mike Smith wrote:
>
> > Did the loader used to set kernelname as an environment variable?
>
> It should still do it. (The forth code handles this) My only Alpha is
> running -stable, and $kernelname is set correctly there (see the output
> of 'kenv').
Not the forth code. The forth code doesn't
Matthew Jacob wrote:
>
> Something actually was changed at some point perhaps?
> On i386, kernelname is dug out of bootinfo and copied
> (in assembler).
>
> On alpha:
>
> p = getenv("kernelname");
> if (p)
> strncpy(kernelname, p, sizeof(kernelname) - 1);
>
>
>
Matthew Jacob wrote:
>
> > Also, in "src/sys/boot/common/boot.c" we still have this:
> >
> > static const char *default_bootfiles = "kernel.ko";
> >
> > which isn't right any more.
>
> Absolutely wrong, yes.
>
> Look at kern_mib.c:
>
>
> char kernelname[MAXPATHLEN] = "/kernel";/*
On Fri, 10 Nov 2000, Matthew Jacob wrote:
> Something actually was changed at some point perhaps?
> On i386, kernelname is dug out of bootinfo and copied
> (in assembler).
i386's used to have this bug. This was fixed in:
RCS file: /home/ncvs/src/sys/i386/i386/locore.s,v
Working file: locore.s
Well, things are more broken than I thought.
The -current loader for alpha is passing "kernel"
in the bootinfo structure- not the full pathname.
Loader bug.
What's amusing is that kenv does see a full pathname.
So, now why did the lines below fail to see the pathname?
Hmmm.. ponders
-mat
> Something actually was changed at some point perhaps?
> On i386, kernelname is dug out of bootinfo and copied
> (in assembler).
>
> On alpha:
>
> p = getenv("kernelname");
> if (p)
> strncpy(kernelname, p, sizeof(kernelname) - 1);
>
>
> Did the loader used to
> > > kernel to have the actual path or not.
> >
> > It is supposed to. Looks like a bug in the alpha startup code somewhere:
> >
> > > uname -a
> > FreeBSD laptop.baldwin.cx 5.0-CURRENT FreeBSD 5.0-CURRENT #40: Fri Nov 10
> > 15:17:48 PST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/LAPTO
> > kernel to have the actual path or not.
>
> It is supposed to. Looks like a bug in the alpha startup code somewhere:
>
> > uname -a
> FreeBSD laptop.baldwin.cx 5.0-CURRENT FreeBSD 5.0-CURRENT #40: Fri Nov 10
> 15:17:48 PST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/LAPTOP-card
> i386
On 11-Nov-00 Matthew Jacob wrote:
>
>
>> Savecore isn't working in -current, dying in my case with "read:
>> invalid argument". (This is on an Alpha -- I don't have an i386
>> -current machine to test it on at the moment.) I traced it down to
>> the fact that getbootfile() is returning "kerne
> Savecore isn't working in -current, dying in my case with "read:
> invalid argument". (This is on an Alpha -- I don't have an i386
> -current machine to test it on at the moment.) I traced it down to
> the fact that getbootfile() is returning "kernel" -- not the full
> pathname as the man pa
In message <[EMAIL PROTECTED]>, Bruce Ev
ans writes:
>Probably that you shouldn't have downgraded savecore by updating it
>:-). savecore now uses devname() but devname() is too unreliable to
>use for anything except informational output.
It always were:
boot
log in
mv /
On Wed, 11 Oct 2000, Jun Kuriyama wrote:
> My boot message of today said:
> Oct 11 10:18:10 waterblue savecore: /dev/#C:116:0x20001: No such file or directory
>
> And swap entry in /etc/fstab is:
> /dev/ad0s1b noneswapsw 0 0
>
> This is non-DEVFS env
On Tue, Oct 10, 2000 at 07:39:40PM -0700, Steve Kargl wrote:
> Jun Kuriyama wrote:
> > My boot message of today said:
> > Oct 11 10:18:10 waterblue savecore: /dev/#C:116:0x20001:\
> > No such file or directory
> >
>
> This is occurring on my machine also. It makes it fairly
> hard to get a cras
Jun Kuriyama wrote:
> My boot message of today said:
> Oct 11 10:18:10 waterblue savecore: /dev/#C:116:0x20001:\
> No such file or directory
>
This is occurring on my machine also. It makes it fairly
hard to get a crash.
--
Steve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscr
Mine has been saying something similar for a week or so now. I just
figured it was me and ignored it. Manually running savecore gives no error
and works fine.
On Wed, 11 Oct 2000, Jun Kuriyama wrote:
> My boot message of today said:
> Oct 11 10:18:10 waterblue savecore: /dev/#C:116:0x20001: No s
In message <199905291221.waa28...@godzilla.zeta.org.au>, Bruce Evans writes:
>>Just found that savecore is broken in the same way. What is proper
>>procedure to fix it? I.e. is it must be fixed in the kernel, leaving
>>userland programs as is or in userland, leaving kernel as is?
>
>The kernel need
>Just found that savecore is broken in the same way. What is proper
>procedure to fix it? I.e. is it must be fixed in the kernel, leaving
>userland programs as is or in userland, leaving kernel as is?
The kernel needs to maintain (or create as necessary for return by
sysctl()) udev_t versions of m
40 matches
Mail list logo
