Dell D830 Broadcom 432AGN WiFi mini PCI-Express

You are talking way to ambiguously (as you would talk to another ndisulator dev), that is, you assume knowledge on the other part ...

When you say "Search in windows registry for those entries", do you mean in .inf file OR in running WinXP and then set and copy those entries in .inf file?
To what do you refer by "reset device"? That is achieved by ...?

Anyway, I did edited .inf file, to set a default values. (I've disabled PowerSaveMode and MinimumPowerConsumption)
Then I've used ndisulator on those, to create new kernel module.

Everything remains same, even sysctl now shows, that those are successfully set, to disabled default value.
Reading from above, "that is irrelevant because they are overridden with OID from if_ndis anyway (by default it is always CAM).", looks like explanation to it, which I can't translate ...
Does it mean that even default written values in .inf file, get overwritten by ...?
To what is OID refering to?
 
OID is one of NDIS ways to call driver code. There are many OIDs ... Explore NDIS API (available on msdn) for more info.

I doubt you will find such entries in windows registry, better search complete disk.

One of you earlier report (3rd) is very interesting (locking issue). Did you reload driver module, without reloading ndis modules, in that case?
 
richardpl said:
OID is one of NDIS ways to call driver code. There are many OIDs ... Explore NDIS API (available on msdn) for more info.

I doubt you will find such entries in windows registry, better search complete disk.
That does it! I am sick and tired of this! You said:
Code:
they are overridden with OID from if_ndis anyway (by default it is always CAM)
I confirm that, when I use v5 drivers, I can see CAM in ifconfig.
However, I would like to edit if_ndis code to NOT override my .inf edited directives.
Because of it, I've been editing .inf for nothing!

richardpl said:
One of you earlier report (3rd) is very interesting (locking issue). Did you reload driver module, without reloading ndis modules, in that case?
Nope. Script handles everything in perfect order.
Shutdown turns off wpa_supplicant, destroys wlan0, unloads ndis-ed_driver, kills ndis_events
Startup load ndis-ed_driver, starts ndis_events, creates wlan0, starts wpa_supplicant.
 
You can make any of set_powersave (or something like that) to just return 0. You actually already did that without any effect.
 
Under WinXP when I've enabled PowerSave mode, even icon indicated associated I couldn't even ping AP
So this might be something else ...

I can also see that ndisulator isn't being developed from begening of January

I've also talked to Weongyo Jeong, regarding BWN(4), which would make my card work and he said:
No plan to add a code for PHY-N drivers. It'll be happened by others not me. :)

regards,
Weongyo Jeong
Who are "others", that are developing it?
 
Seeker said:
Under WinXP when I've enabled PowerSave mode, even icon indicated associated I couldn't even ping AP
So this might be something else ...
rum(4) driver in HOSTAP mode does not have support for power save stuff, also mentioned in manual page.
Do you have similar problems with other APs?

Seeker said:
I can also see that ndisulator isn't being developed from begening of January
I live in same country as you - does this ring a bell somehow?

Seeker said:
Who are "others", that are developing it?

I do not know.
 
Try to disable SMP:
Code:
kern.smp.disabled=1
in /boot/loader.conf.

This is not real fix but might show where the real problem is.
 
I have a related issue with bcm4353 on amd64.

Broadcom driver bcmwl564.sys ver 5.100.9.142 loads successfully and able to scan networks, unfortunately results are not stable, ssid list becomes empty periodically. But I'm not able to connect, status remains 'no carrier'

Setting debug.ndis=1 spawns console with the same messages, looks like driver returns NDIS_STATUS_ADAPTER_NOT_READY on OID_802_11_BSSID call. Any idea how to fix it?

Code:
ndis0: <Broadcom 802.11n Network Adapter> mem 0xfb300000-0xfb303fff irq 17 at device 0.0 on pci18
wlan0: Ethernet address: 78:e4:00:12:53:c4
ndis_request_info:req 0 sc 0xfffffe007efa4000 oid 0D010101 buf 0xfffffe0006b9fa00 buflen 6 written 0 needed 0 rval C0010011
ndis_request_info:req 0 sc 0xfffffe007efa4000 oid 0D010101 buf 0xfffffe00a6120360 buflen 6 written 0 needed 0 rval C0010011
ndis_request_info:req 0 sc 0xfffffe007efa4000 oid 0D010101 buf 0xfffffe010190e470 buflen 6 written 0 needed 0 rval C0010011
ndis_request_info:req 0 sc 0xfffffe007efa4000 oid 0D010101 buf 0xfffffe00a61200e0 buflen 6 written 0 needed 0 rval C0010011
ndis_request_info:req 0 sc 0xfffffe007efa4000 oid 0D010101 buf 0xfffffe0055f026d0 buflen 6 written 0 needed 0 rval C0010011
ndis_request_info:req 0 sc 0xfffffe007efa4000 oid 0D010101 buf 0xfffffe00a61201f0 buflen 6 written 0 needed 0 rval C0010011
ndis_request_info:req 0 sc 0xfffffe007efa4000 oid 0D010217 buf 0xffffff8014e20000 buflen 65535 written 124 needed 0 rval 00000000
ndis_request_info:req 0 sc 0xfffffe007efa4000 oid 0D010101 buf 0xfffffe0006b9f900 buflen 6 written 0 needed 0 rval C0010011
ndis_request_info:req 0 sc 0xfffffe007efa4000 oid 0D010101 buf 0xfffffe00a6120460 buflen 6 written 0 needed 0 rval C0010011
ndis_request_info:req 0 sc 0xfffffe007efa4000 oid 0D010101 buf 0xfffffe00a6120360 buflen 6 written 0 needed 0 rval C0010011
ndis_request_info:req 0 sc 0xfffffe007efa4000 oid 0D010101 buf 0xfffffe00a61203f0 buflen 6 written 0 needed 0 rval C0010011
ndis_request_info:req 0 sc 0xfffffe007efa4000 oid 0D010101 buf 0xfffffe00a6120520 buflen 6 written 0 needed 0 rval C0010011
ndis_request_info:req 0 sc 0xfffffe007efa4000 oid 0D010101 buf 0xfffffe00a60806d0 buflen 6 written 0 needed 0 rval C0010011
ndis_request_info:req 0 sc 0xfffffe007efa4000 oid 0D010101 buf 0xfffffe0055f02610 buflen 6 written 0 needed 0 rval C0010011
ndis_request_info:req 0 sc 0xfffffe007efa4000 oid 00010107 buf 0xffffff81b62868f4 buflen 4 written 4 needed 0 rval 00000000
ndis_request_info:req 0 sc 0xfffffe007efa4000 oid 00010107 buf 0xffffff81b62868f4 buflen 4 written 4 needed 0 rval 00000000
ndis_request_info:req 0 sc 0xfffffe007efa4000 oid 00010107 buf 0xffffff81b62868f4 buflen 4 written 4 needed 0 rval 00000000
ndis_request_info:req 0 sc 0xfffffe007efa4000 oid 0D010101 buf 0xfffffe00a6080300 buflen 6 written 0 needed 0 rval C0010011
ndis_request_info:req 0 sc 0xfffffe007efa4000 oid 0D010101 buf 0xfffffe0055f02610 buflen 6 written 0 needed 0 rval C0010011
ndis_request_info:req 0 sc 0xfffffe007efa4000 oid 0D010101 buf 0xfffffe00a60806e0 buflen 6 written 0 needed 0 rval C0010011
ndis_request_info:req 0 sc 0xfffffe007efa4000 oid 0D010101 buf 0xfffffe0055f02580 buflen 6 written 0 needed 0 rval C0010011
ndis_request_info:req 0 sc 0xfffffe007efa4000 oid 0D010217 buf 0xffffff8014c2b000 buflen 65535 written 124 needed 0 rval 00000000
ndis_request_info:req 0 sc 0xfffffe007efa4000 oid 0D010101 buf 0xfffffe00a6080a60 buflen 6 written 0 needed 0 rval C0010011
ndis_request_info:req 0 sc 0xfffffe007efa4000 oid 0D010101 buf 0xfffffe0006b9fa00 buflen 6 written 0 needed 0 rval C0010011
ndis_request_info:req 0 sc 0xfffffe007efa4000 oid 0D010101 buf 0xfffffe00a6120610 buflen 6 written 0 needed 0 rval C0010011
ndis_request_info:req 0 sc 0xfffffe007efa4000 oid 0D010101 buf 0xfffffe0055f028d0 buflen 6 written 0 needed 0 rval C0010011
ndis_request_info:req 0 sc 0xfffffe007efa4000 oid 0D010101 buf 0xfffffe00a6080410 buflen 6 written 0 needed 0 rval C0010011
ndis_request_info:req 0 sc 0xfffffe007efa4000 oid 0D010101 buf 0xfffffe00a61204b0 buflen 6 written 0 needed 0 rval C0010011

While trying to make it work I've also experienced occasional panics on ifconfig wlan0 scan. The following patch seems to fix it:

Code:
commit 180539b0bebaf32bbffb4b51fb198d9269ce66a7
Author: Gleb Kurtsou <gleb.kurtsou@gmail.com>
Date:   Sun Mar 27 23:39:38 2011 +0300

    Fix panic in ndis_get_bssid_list, clear result on error

diff --git a/sys/dev/if_ndis/if_ndis.c b/sys/dev/if_ndis/if_ndis.c
index e960cd9..967c749 100644
--- a/sys/dev/if_ndis/if_ndis.c
+++ b/sys/dev/if_ndis/if_ndis.c
@@ -2114,8 +2114,10 @@ ndis_get_bssid_list(struct ndis_softc *sc, struct ndis_80211_bssid_list_ex **bl)
 			return;
 		rval = ndis_get(sc, OID_802_11_BSSID_LIST, *bl, len);
 	}
-	if (rval)
+	if (rval) {
 		free(*bl, M_NDIS_DEV);
+		*bl = NULL;
+	}
 }
 
 static void

I've used recent ndisulator version from github.
 
It returns that because client is not associated.

I need more info, like what is AP running and what kind of authentication/encryption. Is ndisevents run in background?

If you want, you can make your clone/code appear on gitorious/github and then I only need to do merge of your fix into "official" tree.
 
richardpl said:
It returns that because client is not associated.

I need more info, like what is AP running and what kind of authentication/encryption. Is ndisevents run in background?

It didn't work with and without ndis_events running. I was trying to connect to another notebook in open and WEP mode. I've just tried it against router with WPA2 and it connected successfully. It seemed to work but system froze up in ~10 minutes. This way be unrelated to ndisulator itself, I've seen several freezes during last week. I'll investigate it further.

Thanks!
 
Deadlocks could be caused by introduction of spinlocks in dpc, worker and sched threads - revert those commits and see if that helps.

It is known bug that sched thread (only if your driver is actually calling NdisScheduleWorkItem()) is panicing very easy SMP systems with heavy CPUs usage. I dunno what is causing this - nothing points that miniport drivers are using non-resident memory (kernel stack) for storing such WorkItems.

amd64 is somehow problematic because some drivers use kuser_shared_data struct which should be updated periodicaly but that caused regression so such code is currently disabled. Amd64 support was broken for many years so reproducing bugs on i386 could point us at right direction.
 
Tell me, richardpl ...

Regarding 9.0
Is your ndisulator code, 100% in it?

Or do I have to continue, to download and install it, as I did up to now.
 
Nope, you will need to download, build, install and so on.
Head of master branch looks to be unstable/broken on SMP systems and I'm currently working on replacing ndisgen/ndiscvt with ndisload which will make easy loading of NDIS drivers. No more need to have source files to build modules from sys/inf files.

9.0 just have code that makes amd64 more usable (no more nasty panic on kldload). Safe use of float registers is not there yet, but I have patch floating around.
 
I am running 8.2-p4 amd64 with ndisulator from the beginning of January, when you had a pause for some time.
I am happy with it, except that after resume from S3 state, ndis0 doesn't appear, after I kldload ndisgen-ed driver.
Code:
# kldload bcmwl564
# ifconfig
pflog0: flags=141<UP,RUNNING,PROMISC> metric 0 mtu 33152
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=3<RXCSUM,TXCSUM>
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
        inet6 ::1 prefixlen 128
        inet 127.0.0.1 netmask 0xff000000
        nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
I must restart (And yes ALL dirivers and all related to it was unloaded/stopped before entering S3 state)

Today I've thrown an eye, at yours site and I can see, there was a LOT of going on there.

There are 2 branches master and stable. Which one is for which BSD version?
You said, master is broken? Then I should go for stable?

ndisload replaces ndisgen?
With what do I "feed" ndisload, if not with driver's sys/inf files?
 
Branch stable is for 8.X
For 9.X you could use older version of master.

Suspend/Resume issues could be partialy related to FreeBSD.

I'm not sure it they have been fixed in 9.0.

Workaround for me was using hw.pci.do_power_nodriver set to 3 and unloading relevant driver and reloading some irrelevant one which attaches to pci but works after resume.
That is workaround for bug where unloading driver will not put relevant device back to S3 state. I'm not sure it this bug have been fixed in 9.0

Right behaviour is to not depend on this hacks but when suspend/resume happens device need to be set into right DX state. NDISulator side of story have been fixed long ago.

Point of ndisload is that it will alow loading driver with only sys file(s). And if additional arguments are not specified (like to which device to attach) it will try to attach to all of them.
 
8.2-p4 amd64
I've used STABLE:
Monday March 28 2011 19:25
richardpl committed 761c8cf
Merge branch 'master' into stable


Worser then ever!

NDIS v4:
All is well, until I initiate download ...
Few sec(IF even that) and global FREEZE -> no err, panics, response, no anything!

NDIS v5: (pics sucks!)
Here I don't even need to initiate download:
http://www.starforce.biz/ndis5/ndis_5_panic_on_assoc.jpg

Once I've succeeded at 3%:
http://www.starforce.biz/ndis5/ndis_5_panic_on_download.jpg
 
5aaaa64

Code:
cruiser# make build install clean
cd /usr/src/sys/modules/ndis && make
Warning: Object directory not changed from original /usr/src/sys/modules/ndis
cc -O2 -pipe -march=native -fno-strict-aliasing -D_KERNEL -DKLD_MODULE -nostdinc   -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 -
-param large-function-growth=1000 -fno-common  -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone  -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3d
now  -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/ndis/../..
/compat/ndis/subr_hal.c
/usr/src/sys/modules/ndis/../../compat/ndis/subr_hal.c: In function 'WRITE_PORT_ULONG':
/usr/src/sys/modules/ndis/../../compat/ndis/subr_hal.c:101: error: 'X86_BUS_SPACE_IO' undeclared (first use in this function)
/usr/src/sys/modules/ndis/../../compat/ndis/subr_hal.c:101: error: (Each undeclared identifier is reported only once
/usr/src/sys/modules/ndis/../../compat/ndis/subr_hal.c:101: error: for each function it appears in.)
/usr/src/sys/modules/ndis/../../compat/ndis/subr_hal.c: In function 'WRITE_PORT_USHORT':
/usr/src/sys/modules/ndis/../../compat/ndis/subr_hal.c:108: error: 'X86_BUS_SPACE_IO' undeclared (first use in this function)
/usr/src/sys/modules/ndis/../../compat/ndis/subr_hal.c: In function 'WRITE_PORT_UCHAR':
/usr/src/sys/modules/ndis/../../compat/ndis/subr_hal.c:115: error: 'X86_BUS_SPACE_IO' undeclared (first use in this function)
/usr/src/sys/modules/ndis/../../compat/ndis/subr_hal.c: In function 'WRITE_PORT_BUFFER_ULONG':
/usr/src/sys/modules/ndis/../../compat/ndis/subr_hal.c:122: error: 'X86_BUS_SPACE_IO' undeclared (first use in this function)
/usr/src/sys/modules/ndis/../../compat/ndis/subr_hal.c: In function 'WRITE_PORT_BUFFER_USHORT':
/usr/src/sys/modules/ndis/../../compat/ndis/subr_hal.c:130: error: 'X86_BUS_SPACE_IO' undeclared (first use in this function)
/usr/src/sys/modules/ndis/../../compat/ndis/subr_hal.c: In function 'WRITE_PORT_BUFFER_UCHAR':
/usr/src/sys/modules/ndis/../../compat/ndis/subr_hal.c:138: error: 'X86_BUS_SPACE_IO' undeclared (first use in this function)
/usr/src/sys/modules/ndis/../../compat/ndis/subr_hal.c: In function 'READ_PORT_USHORT':
/usr/src/sys/modules/ndis/../../compat/ndis/subr_hal.c:146: error: 'X86_BUS_SPACE_IO' undeclared (first use in this function)
/usr/src/sys/modules/ndis/../../compat/ndis/subr_hal.c: In function 'READ_PORT_ULONG':
/usr/src/sys/modules/ndis/../../compat/ndis/subr_hal.c:153: error: 'X86_BUS_SPACE_IO' undeclared (first use in this function)
/usr/src/sys/modules/ndis/../../compat/ndis/subr_hal.c: In function 'READ_PORT_UCHAR':
/usr/src/sys/modules/ndis/../../compat/ndis/subr_hal.c:160: error: 'X86_BUS_SPACE_IO' undeclared (first use in this function)
/usr/src/sys/modules/ndis/../../compat/ndis/subr_hal.c: In function 'READ_PORT_BUFFER_ULONG':
/usr/src/sys/modules/ndis/../../compat/ndis/subr_hal.c:167: error: 'X86_BUS_SPACE_IO' undeclared (first use in this function)
/usr/src/sys/modules/ndis/../../compat/ndis/subr_hal.c: In function 'READ_PORT_BUFFER_USHORT':
/usr/src/sys/modules/ndis/../../compat/ndis/subr_hal.c:175: error: 'X86_BUS_SPACE_IO' undeclared (first use in this function)
/usr/src/sys/modules/ndis/../../compat/ndis/subr_hal.c: In function 'READ_PORT_BUFFER_UCHAR':
/usr/src/sys/modules/ndis/../../compat/ndis/subr_hal.c:183: error: 'X86_BUS_SPACE_IO' undeclared (first use in this function)
*** Error code 1

Stop in /usr/src/sys/modules/ndis.
*** Error code 1
 
Finally I can say, this is a best release from you, up to now!

With ALL versions, there is initial lag present upon request, but my AP might be to blame.

I.e;
URL(example.com/target_file) at my AP is requested. Hangs ...
URL at my AP is redirected to http://www.example.com/target_file. Hangs ...
Big file is being fetched, with stable continuous speed.


Each tested with few creates/destroys to absolute 0
NDISv4
Works, but speed is always crappy ~150 Kb/s

NDISv5
Now finally I am always getting ~490 Kb/s and up to ~650 Kb/s, which is a Win7 score.

S3 state
Before entering S3, all is destroyed to absolute 0
Upon "comeback", during kldloading modules ndis0 device doesn't appear anymore!
I've tried unloading and loading nvidia.ko module, as a side stuff, then tried again and nothing happens.
 
For example:

Code:
ndis0@pci0:2:3:0:       class=0x028000 card=0x120f1043 chip=0x431814e4 rev=0x02 hdr=0x00
    vendor     = 'Broadcom Corporation'
    device     = 'BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller'
    class      = network

this is output from pciconf -lvc.

As you can see there is no cap which would mention powerspec D0 - D3.

If you see this it means FreeBSD will not put device into D3 state upon suspend ever.

This is FreeBSD bug.

So does your device have cap line?
 
Why would it(D states), be relevant at all, if I destroy/create device via script.
When I turn on laptop, there doesn't exist anything WiFi related, so:[CMD="pciconf"]-lvc[/CMD], won't show ndis0, as it doesn't exist.
Exactly in this state, I enter into S3 state, immediately after power on and root login.
Upon combeack I: (create ndis0 for a first time, from power on)
[CMD="bcmwl564"]kldload[/CMD]
ndis0 isn't created! Simply nothing happens!
This isn't a question/case, of going into S3, WITH EXISTING ndis0.

But for your curiosity:
[CMD="bcmwl564"]kldload[/CMD][CMD="pciconf"]-lvc[/CMD]
Code:
ndis0@pci0:12:0:0:      class=0x028000 card=0x000a1028 chip=0x432814e4 rev=0x03 hdr=0x00
    vendor     = 'Broadcom Corporation'
    device     = 'Broadcom 432AGN 802.11a/b/g/draft-n Wi-Fi Solution (BCM4321KFBG)'
    class      = network
    cap 01[40] = powerspec 2  supports D0 D1 D2 D3  current D0
    cap 09[58] = vendor (length 120)
    cap 05[e8] = MSI supports 1 message, 64 bit
    cap 10[d0] = PCI-Express 1 endpoint max data 128(128) link x1(x1)

Problem 2:
I took my laptop and went to the local caffe, which has unencrypted WiFi AP.

Once scan is initiated, with NDISv5, I get panics:
http://www.starforce.biz/ndis5/ndis5_scan_panic1.jpg
http://www.starforce.biz/ndis5/ndis5_scan_panic2.jpg
http://www.starforce.biz/ndis5/ndis5_scan_panic3.jpg
http://www.starforce.biz/ndis5/ndis5_scan_panic4.jpg
NDISv5 obviously has a problem with unencrypted APs, during scan!

Then I've ndisulated NDISv4 driver version and successfully connected, as there were no more panics.
However, I even here had a speed of ~150 Kb/s(same as at home AP), BUT there was no LAG as there is with my home AP!
 
It is FreeBSD bug because FreeBSD kernel is responsible for puting device into D3 state before suspend.
If you kldunload driver before suspend check that pciconf output for relevant device have "current D3".

If device is not put into D3 state before suspend it may not correctly wake up after resume - so trying to kldload driver will not work because driver will fail to initialize device and ndis0 will never appear again until you reboot machine.

I think that this bug have been fixed in FreeBSD 9.0

The panic is same as any other panic you have been posting all these years - it is SMP bug in NDISulator and not some trivial one - it is bug by DESIGN.

If it happens with UP kernel than I will try to fix it ASAP.

As always best way to report any bug is to report in on github page bellow where project is currently located.

There you can create own issue number and post whatever you want.

I do not want to abuse this forum for something it is obviously not made for.
 
richardpl said:
It is FreeBSD bug because FreeBSD kernel is responsible for puting device into D3 state before suspend.
If you kldunload driver before suspend check that pciconf output for relevant device have "current D3".

If device is not put into D3 state before suspend it may not correctly wake up after resume - so trying to kldload driver will not work because driver will fail to initialize device and ndis0 will never appear again until you reboot machine.

I think that this bug have been fixed in FreeBSD 9.0
You gave me an explanation, of a case where ndis device existed before S3.
In my(second) case, ndis is created for a first time, after resume from S3.
richardpl said:
The panic is same as any other panic you have been posting all these years - it is SMP bug in NDISulator and not some trivial one - it is bug by DESIGN.
I wouldn't be able to classify a problem, from the pics.
Well ... if after all these years, it is still present, then it must be really deeply nested! ;)
OS level SMP or ndis level SMP?

I can't set device power state?
Also ...
Code:
# sysctl dev.ndis
Has no effect!
richardpl said:
If it happens with UP kernel than I will try to fix it ASAP.
What is a UP kernel?!
 
It is completly irrelevant if or when ndis0 is created, ndis0 is just driver attached to device on pci bus (in your case).
Device must be put in S3 state when suspending. It can not be done from NDISulator in any way. NDISulator can only say to driver(and that is exactly what it is doing for a while) that device is going to enter S3 state and then driver prepare itself (stoping any actions on his level and preparing device for S3 state).
Actual change of device power state is done by FreeBSD pci bus code.

UP is kernel without SMP in kernel conf.

UP kernel does not make use of multiple CPUs at same time.

There is also PREEMPTION which means that kernel scheduler can stop some kernel threads in middle of their work and resume other threads ....

What you mean that sysctl on dev.ndis have not effect?

dev.ndis will have entries after creating at least one succesfully operating & attached driver to device (ndis0).
 
Back
Top