64bit ndis ar5008 module crashes kldload

J

jwhendy

Hi,


I have another post that explains what I was trying to do with my MacBook, essentially to get a wireless driver with it. The thread ends with me finding success by installing i386 and using ndisgen to create some drivers from winxp drivers I found for my card.

I'm okay with sticking with i386 if I must, but I'd like to run amd64 if possible. So, I reinstalled amd64 FreeBSD 7.0 to try one last time.

I found several 64bit XP drivers that I've tried using the same ndisgen procedure, but each time the computer crashes. I only have 15 seconds to read the messages before the reboot, and I'm not sure what log file to look at after the reboot other than dmesg and /var/log/messages... So, based on that, this is what I have:

/var/log/messages:
Code: 
Jan 12 18:13:48 jwhendy kernel: ndis0: <Atheros 5008 Wireless Network Adapter> mem 0x90100000-0x9010ffff irq 17 at device 0.0 on pci2
Jan 12 18:13:48 jwhendy kernel: ndis0: [ITHREAD]
Jan 12 18:13:48 jwhendy kernel: ndis0: NDIS API version: 5.1
Jan 12 18:15:58 jwhendy syslogd: kernel boot file is /boot/kernel/kernel

boot message after crash/reboot is something like:
Code: 
page fault while in kernel mode
panic on vm_fault no fault entry

My initial thought is that the report in /var/log/messages indicates that the driver attached to to the device and correctly identified it - that's really hopeful I think. On normal boot, the device is not even identified (just as '<network card> no driver attached on 0:0 pci2').

I've tried searching for how to debug crashes, kernel dump log files, etc. but have not found a good place to learn about what to do after this. I know there was more stuff on the screen when it crashed, but I only have 15sec before reboot to read it. Does that stuff get written somewhere?

Anyone with any ideas on how to solve this? What might be causing the crash? Anyone with experience on ndis who might know what I could do to change the .inf/.sys files so they work?


Thanks for any help for a newb!
John
 
This is ndisulator bug.
You can provide textdump() from kernel panic if you are using 7.1
You will need at least DDB and KDB enabled in kernel.

With bt from textdump we could find where panic happened - first step in fixing bug.
 
update: just found vmcore.0 and vmcore.1. They will probably be similar. Here's what is right before and after the module was loaded:
Code: 
no match for ZwCreateKey
no match for IoOpenDeviceRegistryKey
no match for ZwDeleteKey
no match for ZwOpenKey
no match for KeBugCheckEx
ndis0: <Atheros AR5008 Wireless Network Adapter> mem 0x90100000-0x9010ffff irq 17 at device 0.0 on pci2
ndis0: [ITHREAD]
ndis0: NDIS API version: 5.1
NDIS: open file /compat/ndis/AW1012d.ini failed: 2
NDIS: open file /compat/ndis/regAdd.txt failed: 2

Fatal trap 1: privileged instruction fault while in kernel mode
cpuid = 1; apic id = 01
instruction pointer = 0x8:0xffffffff813ed006
stack pointer = 0x10:0xffffffffaf7201e0
frame pointer = 0x10:0xffffffffaf720210
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 1623 kldload
trap number = 1
panic: privileged instruction fault
cpuid = 1
Uptime 23m6s

After that it looks like the beginning of the next boot... lots of nondiscernible characters, i386 loader things mixed in...

Thoughts?


Thanks,
John
 
Richard, I was posting when you posted...

I'm at 7.0 right now. I upgraded via internet to 7.1 previously, but don't want to do that until I rule out amd64 (if that's what's going to happen). If it happens that I have to use i386 I'll do everything from scratch and upgrade to 7.1 at that point. I don't want to burn another CD/DVD and I'd prefer to wait for the upgrade only after I've figured out the arch I'm going to stick with. If you think there's a significant advantage to upgrading and chance to solve the problem, I'll do it.

Let me know if I need to recompile the kernel in 7.0 with DBB/KDB. I am not familiar with those options, but I just searched GENERIC and neither of them are listed.


Thanks,
John
 
If you care that this bug on amd64 get fixed you can install 7.1 amd64 and got textdump from crash.
Once textdump is available it helps debug problem veeery fast, because bt from textdump is very short and useful piece of data

Alternatively, you are the only one who could debug vmcore files because they are machine dependent.
Debugging kernel crash dump with kgdb() is explained
in developers-handbook and it is not for newcomers.
 
jwhendy said:
Let me know if I need to recompile the kernel in 7.0 with DBB/KDB. I am not familiar with those options, but I just searched GENERIC and neither of them are listed.
Click to expand...
As already mentioned textdumps are available only with 7.1 and higher.
 
Sounds good - I'll upgrade to 7.1 and recompile with DBB & KDB.

Questions:
- Do I cp GENERIC ./MYCONFIG and add
Code: 
option DBB
option KDB
to the file and then recompile?

- How do I use the textdump to obtain the bt? All I'm finding (perhaps because it's a new feature) is this for the most part. Not really seeing a 'how to'. Could you post a set of instructions? The handbook showed nothing when I searched it for 'textdump'.

Thanks,
John
 
Update:

- Upgraded to 7.1
- Recompiled kernel with options DDB and KDB
- Did 'ddb script "such and such" ' that I found in the textdump man page to set textdump on, etc.
- Checked that it was on using sysctl
- Loaded the module, and the 'usual' occurred, but instead of rebooting, I got a db> command line.

I typed in 'bt' at the db> command line and get this:
Code: 
Tracing pid 1077 tid 100097 td 0xffffff0003f76000
_end() at 0xffffffff813f7000
NdisMSynchronizeWithInterrupt() at NdisMSynchronizeWithInterrupt+0xc
dmapbase() at 0xffffff0003cff1ce
athwx_sys_drv_data_start() at 0xffffffffaf7259d3

What do you make of that? Is it something fixable such that the driver has a chance at working?

Let me know if there's anything else you'd like. I wasn't very familiar with the textdump/ddb/kdb procedure in general, so thankfully I even remembered to type 'bt' at the db> prompt! If there's something else you'd like posted, that'd be great to know. I know textdump generates some other files, to tomorrow I'll see if I can find those if they'd be helpful.


Thanks,
John
 
Thanks, Richard. I'm at work but will do both things when I get home tonight.

Thanks for the help,
John
 
I disabled smp, rebooted, and tried loading the module. At the db prompt I got the output of bt again and compared it to the original posted above. They have slight differences... Here is the one with smp disabled:

Code: 
Tracing pid 923 tid 100070 td 0xffffff0003ad06e0
_end() at 0xffffffff813f7000
NDISMSynchronizeWithInterrupt() at NdisMSynchronizeWithInterrupt+0xc
dmapbase() at 0xffffff0003ae1c4e
athwx_sys_drv_data_start() at 0xffffffffaf6e09d3

I'll send both of these to the dev site you recommended earlier. Any other ideas to try? Are these memory references? Are these references to a method (I have a little knowledge of Java)?

Thanks,
John
 
jwhendy said:
Are these memory references? Are these references to a method (I have a little knowledge of Java)?
Click to expand...
They are references to source code lines, but in your case they do not help much because most interesting parts are hiden somewhere else in miniport driver.

You could enable sysctl debug.ndis=1 and maybe more usefull kernel info will come up on next crash.
 
When I 'sysctl -a|grep ndis' I get no results. I tried doing 'sysctl debug.ndis=1' and got 'sysctl: unknown oid 'debug.ndis''. Is it a kernel option I need to enable?

Thanks,
John
 
I'll try that, but don't have high hopes. I haven't heard anything from the developer posting I made yet - what's an estimate of how long they usually might take to respond to a problem? I well understand that there's many problems for developers more important than this one, but just wondered what my timeline might look like for this.

Is there anyone who would know whether what I'm trying is even possible?


Thanks,
John
 
I see your bug report. It will take some time for bugmaster team to forward it to net@ developers, and after that one of developers(comiter) may pick it and work on it .....

If you are interested more how all this stuff works read other books available
usually in /usr/share/doc/en/books/
In same directory where handbook is.

I see you did not reported that some functions were missing - but it is not probably cause of problem because your card already works on i386.
 
Thanks for checking the report and I will definitely check the documentation you referenced. The time issue is only frustrating as I want to make the decision on whether to just go with i386 or amd64. I'm only holding out for amd64 if wireless works. I just don't think I would want a laptop with FreeBSD when wireless wouldn't work. At one point I thought it wasn't possible with either version, but now that I have seen it work I will use i386 for that reason...

Regarding the drivers, yes, I'm using 64bit Win XP drivers. I got them from this SITE, used a Win machine to extract the .exe, and then went in the resulting directory. There's an 'XP drivers' folder and then an XP32bit and XP64bit folder. One oddity is that both .inf files (for the 32bit and 64bit drivers) say:

- Installs athw.sys (NDIS 5/5.1 driver) on NT platforms (2000, XP and greater)
- Installs athwx.sys (NDIS 5 driver) on 9x platforms

The drivers inside the 32bit folder are titled athx.sys and netathw.inf, and those in the 64bit folder are athwx.sys and netathwx.inf. What's weird is that the .inf file says that athwx.sys is for 9x platforms, which is Win 95/98, not 64bit XP!?!

Anyway, despite this, even though the driver is crashing things it at least is picking up the NIC before it does. It IS working to a degree. None of the other drivers even see and attach to the card; this one does, it's just also causing a kernel panic.

In case you're at all interested to see the drivers, you can get them here:
Win32bit.inf
Win32bit.sys
Win64bit.inf
Win64bit.sys

Thanks for your continued input!


-John
 
You must log in or register to reply here.
Back
Top