From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 18:46:35 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id 691E616A420; Thu, 10 Nov 2005 18:46:35 +0000 (GMT) In-Reply-To: <43737817.8030300@mcsi.pp.ru> from Maxim Maximov at "Nov 10, 2005 07:40:55 pm" To: mcsi@mcsi.pp.ru (Maxim Maximov) Date: Thu, 10 Nov 2005 18:46:35 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20051110184635.691E616A420@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) Cc: freebsd-current@freebsd.org Subject: Re: CURRENT panics sometimes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2005 18:46:35 -0000 > Hi. > > 1 boot of 3 I got similar panics in softclock(). > > kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x218 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc06aa6ae > stack pointer = 0x28:0xd4710cac > frame pointer = 0x28:0xd4710cd4 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 13 (swi4: clock sio) > > The trace is: > > softclock(0) ... +0x86 > ithread_execute_handlers > ithread_loop > fork_exit > form_trampoline > > softclock+0x86 is here (marked with an arrow) > > /* > * softticks may be modified by hard clock, so cache > * it while we work on a given bucket. > */ > curticks = softticks; > bucket = &callwheel[curticks & callwheelmask]; > c = TAILQ_FIRST(bucket); > while (c) { > depth++; > ---> if (c->c_time != curticks) { > c = TAILQ_NEXT(c, c_links.tqe); > ++steps; > > Debugging shows that 'c' has the value of 0x210. Which is incorrect for > sure. 'c_time' has an offset of 0x8, giving us fault virtual address. > I'm using NDIS. It seems, that panic happens on first packet NDIS tries > to send. This is when 'ntpdate' is being run at boot stage. > As I said, I can reproduce it by rebooting a few times. Can anyone give > a clue where to look in DDB further to help to resolve this problem? If you want us to give you clues, you have to give _US_ clues. For example, here are some of the things you didn't bother to say: - _WHICH_ windows driver are you using with NDIS? - _WHAT_ wireless card do you have? - Complete dmesg output from your system (note: verbose boot is not necessary, but _full_ output is necessary, i.e. don't remove things you think are unimportant) - Did you add your NDIS driver to /boot/loader.conf, or are you loading the driver after the system is running multiuser? - If you are loading the driver via /boot/loader.conf, did you try _not_ doing that, and loading it afterwards? - What kind of system is this? Laptop? Desktop? Stone knives and bearskins? - Is it SMP or UP? When you provide this information, maybe you will get help. NOTE: Windows NDIS drivers assume that by the time you intialize them, the entire OS is up and running, including scheduling and, if present, multiple CPUs. But in FreeBSD, the kernel is running in 'cold start' state when it probes/attaches devices, and not all of the scheduling mechanisms are available yet (for example, you can not msleep() while cold == 1). This means loading your driver via /boot/loader.conf is something of a hit-or-miss proposition: sometimes they don't work right, sometimes they do. To be really safe, you should load them _after_ the system has come up all the way. Unfortunately, it's necessary to initialize the driver briefly in ndis_attach() in order to find out the device's station address. (You can only do it via MiniportQueryInformation(), and that only works after MiniportInitialize() has been called.) -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= you're just BEGGING to face the moose =============================================================================