Re: CURRENT panics sometimes

> 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_at_windriver.com | Wind River Systems
=============================================================================
              <adamw> you're just BEGGING to face the moose
=============================================================================