Date: Wed, 18 Feb 1998 00:28:52 +0100 From: Eivind Eklund <eivind@yes.no> To: Mike Smith <mike@smith.net.au> Cc: hackers@FreeBSD.ORG Subject: Re: ed overwrite clue? Message-ID: <19980218002852.55010@follo.net> In-Reply-To: <199802172300.PAA03354@dingo.cdrom.com>; from Mike Smith on Tue, Feb 17, 1998 at 03:00:34PM -0800 References: <19980217234852.01126@follo.net> <199802172300.PAA03354@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Feb 17, 1998 at 03:00:34PM -0800, Mike Smith wrote: > > On Tue, Feb 17, 1998 at 02:27:32PM -0800, Mike Smith wrote: > > I've been looking more closesly now - I'm having the destination > > addresses switch between 0xefbX XXXX and 0xf01X XXXX. The > > 0xf01*-addresses never crash. And there are much more of the > > 0xf01*-addresses - I've seen hundreds of 0xf01* pass without getting > > any crashes, while between 10% and 20% of the 0xefb* crash. (But not > > 100%, which makes this more complicated). > > I think what you're seeing there is you're taking interrupts on two > different stacks. The 0xefb* addresses are around _kstack, which is at > 0xefbfe000. The other one could be the user stack. _kstack is the bottom end of the stack; the top end looks like it is at 0xefc0000. All of the crashing addresses I've seen so far are in the top 256 bytes of the kstack, so it doesn't look like I'm running out of stack. > Beware that the kernel stack is small (only a few K). You might want > to see whether the values that are causing the problem are all below > some threshold (IIRC the kernel stack allocation is about 7K). It's exactly 8k, if I read the sources correctly. > > I'm about to start trigging some crashdumps on purpose now, so I can > > get a good look at how a dump for an OK case is. > > Do you have any custom code in the kernel? Yes. And the system won't boot without it, so ripping it out is really not an option. I could try to revert as much as possible, but it really doesn't look like any of the code that is revertible is at fault; almost none of it has been excersised yet. The only part that has been excersised that I can see might be relevant is the PnP probe in the ed driver; that's the exact same probe I committed to -current a couple of weeks ago. The kernel I'm debugging is a 2.2.2 with many parts merged from -current and RELENG_2_2, and some special tuneups (the tty-buffers is increased from 100 to 1600 bytes, for instance, but as it seems to be very very far from extinguishing the stack space, this shouldn't be of concern). And the exact same kernel run fine with another NE2000-clone (on another port and IRQ, though, but there are no IRQ-conflicts). Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980218002852.55010>