DWL-G520 rev B3 not working under ath driver (was Re: ndis0: link down after idle time)
I've tracked this down to an error in src/share/misc/pci_vendors.h,v 1.30.2.2; and from browsing in cvsweb it appears that no current version of this file has the correct data: 168CAtheros Communications Inc. 0007AR5000 802.11a Wireless Adapter 0011AR5210 802.11a Wireless Adapter 0012AR5211 802.11a/b/g Mini-PCI Wireless Adapter 0013AR5213 802.11a/b/g Wireless Adapter but the current output of http://www.pcidatabase.com/reports.php?type=tab-delimeted is this: 168CAtheros Communications Inc. 0007AR5000 802.11a Wireless Adapter 0011AR5210 802.11a Wireless Adapter 0012AR5211 802.11a/b/g Mini-PCI Wireless Adapter 0013AR5212, AR5213 802.11a/b/g Wireless Adapter In the current pci vendors list, 168C 0013 should indicate both AR5212 and AR5213. The 5213 is apparently an a/b/g chip used in the DWL-G530, and since I have the DWL-G520 that uses the AR5212 I do have a supported card under the ath driver.. but the driver failed to load, so something is wrong. I will try the ath driver again soon and post results for it. On 1/24/2005, "Hendrik Spiegel" <[EMAIL PROTECTED]> wrote: >Hi, > >I use the same D_Link card as you do, although I use it successfully >with the native ath driver. > >On Sun, 2005-01-23 at 22:23 -0600, [EMAIL PROTECTED] wrote: >> I am running FreeBSD 5.3-stable and have had limited success with a >> d-link DWL-G520 card, rev B3 (atheros ar5213 chipset). I had hoped that >> I would have purchased a card with a supported native driver (ath), > >You probably did ;) >> The card works well, albeit only in 802.11b 11mb/s adhoc mode, > >I can reproduce this with the native driver. 11g is sometimes down to a >few kBit and 500-1000ms when I switch to 11b speed is ok and times are >25-40ms. > > >> that I can't figure out. After about an hour or so of idle time on the >> link, the interface brings itself down and cannot be resurrected unless >> I issue a command through ifconfig to bring the interface up again. Does >> anyone else experience this problem and/or have a solution? > >I will watch this - I do not remember exactly if there were such >problems. > >FreeBSD mars.local 5.3-RELEASE-p2 FreeBSD 5.3-RELEASE-p2 #0: Mon Jan 10 >23:27:32 CET 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BTKERNEL >i386 > >[EMAIL PROTECTED]:9:0: class=0x02 card=0x3a131186 chip=0x0013168c rev=0x01 >hdr=0x00 >vendor = 'Atheros Communications Inc.' >device = 'AR5213 802.11a/b/g Wireless Adapter' >class= network >subclass = ethernet > >ath0: flags=8843 mtu 1500 >inet 192.168.0.2 netmask 0xff00 broadcast 192.168.0.255 >ether 00:0f:3d:ab:9a:b6 >media: IEEE 802.11 Wireless Ethernet autoselect mode 11b >(DS/11Mbps) >status: associated >ssid LokalHorst 1:LokalHorst >channel 4 authmode OPEN powersavemode OFF powersavesleep 100 >rtsthreshold 2312 protmode CTS >wepmode MIXED weptxkey 1 >wepkey 1:104-bit > > ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ndis0: link down after idle time
Hendrik - are you certain it is a rev. B3 with the ar5213 chipset? The ath driver on my box attempts to hook, but fails. I get these kernel messages: ath0: mem 0xd680-0xd68 0 irq 5 at device 10.0 on pci0 ath0: unable to attach hardware; HAL status 13 kernel: device_attach: ath0 attach returned 6 On 1/24/2005, "Hendrik Spiegel" <[EMAIL PROTECTED]> wrote: >Hi, > >I use the same D_Link card as you do, although I use it successfully >with the native ath driver. > >On Sun, 2005-01-23 at 22:23 -0600, [EMAIL PROTECTED] wrote: >> I am running FreeBSD 5.3-stable and have had limited success with a >> d-link DWL-G520 card, rev B3 (atheros ar5213 chipset). I had hoped that >> I would have purchased a card with a supported native driver (ath), > >You probably did ;) >> The card works well, albeit only in 802.11b 11mb/s adhoc mode, > >I can reproduce this with the native driver. 11g is sometimes down to a >few kBit and 500-1000ms when I switch to 11b speed is ok and times are >25-40ms. > > >> that I can't figure out. After about an hour or so of idle time on the >> link, the interface brings itself down and cannot be resurrected unless >> I issue a command through ifconfig to bring the interface up again. Does >> anyone else experience this problem and/or have a solution? > >I will watch this - I do not remember exactly if there were such >problems. > >FreeBSD mars.local 5.3-RELEASE-p2 FreeBSD 5.3-RELEASE-p2 #0: Mon Jan 10 >23:27:32 CET 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BTKERNEL >i386 > >[EMAIL PROTECTED]:9:0: class=0x02 card=0x3a131186 chip=0x0013168c rev=0x01 >hdr=0x00 >vendor = 'Atheros Communications Inc.' >device = 'AR5213 802.11a/b/g Wireless Adapter' >class= network >subclass = ethernet > >ath0: flags=8843 mtu 1500 >inet 192.168.0.2 netmask 0xff00 broadcast 192.168.0.255 >ether 00:0f:3d:ab:9a:b6 >media: IEEE 802.11 Wireless Ethernet autoselect mode 11b >(DS/11Mbps) >status: associated >ssid LokalHorst 1:LokalHorst >channel 4 authmode OPEN powersavemode OFF powersavesleep 100 >rtsthreshold 2312 protmode CTS >wepmode MIXED weptxkey 1 >wepkey 1:104-bit > > ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ndis0: link down after idle time
I am running FreeBSD 5.3-stable and have had limited success with a d-link DWL-G520 card, rev B3 (atheros ar5213 chipset). I had hoped that I would have purchased a card with a supported native driver (ath), but alas! The card was supposed to have used the 5212 chipset, which is supported by the ath driver. The ndis driver will only bring the link up if the media is forced to adhoc mode, which seems to be common from my limited viewing of reports in the mailing lists. The card works well, albeit only in 802.11b 11mb/s adhoc mode, but there is a major problem that I can't figure out. After about an hour or so of idle time on the link, the interface brings itself down and cannot be resurrected unless I issue a command through ifconfig to bring the interface up again. Does anyone else experience this problem and/or have a solution? Attached below is all pertinent information I can think of: uname -a output: FreeBSD [hidden] 5.3-STABLE FreeBSD 5.3-STABLE #7: Tue Jan 18 21:47:38 CST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/HAUTLOS i386 pciconf -lv output for the device: [EMAIL PROTECTED]:10:0:class=0x02 card=0x3a131186 chip=0x0013168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR5213 802.11a/b/g Wireless Adapter' class= network subclass = ethernet ifconfig ndis0: ndis0: flags=8843 mtu 1500 inet 192.168.2.1 netmask 0xff00 broadcast 192.168.2.255 inet6 fe80::211:95ff:fe8d:1379%ndis0 prefixlen 64 scopeid 0x1 ether 00:11:95:8d:13:79 media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps ) status: associated ssid deutschland 1:deutschland channel 6 authmode OPEN powersavemode OFF powersavesleep 100 rtsthreshold 2312 protmode CTS wepmode OFF weptxkey 1 available sysctls for dev.ndis.0: dev.ndis.0.%desc: D-Link AirPlus DWL-G520 Wireless PCI Adapter(rev.B) dev.ndis.0.%driver: ndis dev.ndis.0.%location: slot=10 function=0 dev.ndis.0.%pnpinfo: vendor=0x168c device=0x0013 subvendor=0x1186 subdevice=0x3a13 class=0x02 dev.ndis.0.%parent: pci0 dev.ndis.0.InitFile: A3AB.ini dev.ndis.0.aifs: 2 dev.ndis.0.cwmin: 15 dev.ndis.0.MapRegisters: 256 dev.ndis.0.NetworkAddress: dev.ndis.0.sleepMode: 0 dev.ndis.0.tpc: 0 dev.ndis.0.shortPreamble: 1 dev.ndis.0.radioEnable: 1 dev.ndis.0.BusType: 5 dev.ndis.0.AdHocChannel: 2437 dev.ndis.0.AwakeTimePerf: 200 dev.ndis.0.beaconInterval: 100 dev.ndis.0.bkScanEnable: 1 dev.ndis.0.bssType: 1 dev.ndis.0.ccode: US dev.ndis.0.clist: dev.ndis.0.defaultKey: 0 dev.ndis.0.EncryptionAlg: 2 dev.ndis.0.FragThreshold: 2346 dev.ndis.0.HwTxRetries: 4 dev.ndis.0.privacyInvoked: 0 dev.ndis.0.QoS: 0 dev.ndis.0.rateCtrlEnable: 1 dev.ndis.0.RTSThreshold: 2346 dev.ndis.0.scanType: 2 dev.ndis.0.SwTxRetryScale: 6 dev.ndis.0.SSID: default dev.ndis.0.NetBand: 28 dev.ndis.0.AdHocBand: 0 dev.ndis.0.NicType: 0 dev.ndis.0.p24GAG: 2 dev.ndis.0.p5GAG: 4 dev.ndis.0.abolt: 255 dev.ndis.0.Environment: 1 dev.ndis.0.NdisVersion: 0x00050001 dev.ndis.0.InterruptNumber: 5 dev.ndis.0.DriverDesc: UNSET dev.ndis.0.BusConfig: UNSET dev.ndis.0.TriggerAdj: UNSET dev.ndis.0.CalibrationTime: UNSET dev.ndis.0.gpioPinFunc0: UNSET dev.ndis.0.gpioPinFunc1: UNSET dev.ndis.0.TransmitRate11a: UNSET dev.ndis.0.TransmitRate11b: UNSET dev.ndis.0.TransmitRate11g: UNSET dev.ndis.0.TransmitRate108g: UNSET dev.ndis.0.TransmitRateTurbo: UNSET dev.ndis.0.TransmitRate11Xr: UNSET dev.ndis.0.antennaSwitch: UNSET dev.ndis.0.writeBlockSize: UNSET dev.ndis.0.MinimumRate11a: UNSET dev.ndis.0.MinimumRate11b: UNSET dev.ndis.0.MinimumRate11g: UNSET dev.ndis.0.MinimumRate108g: UNSET dev.ndis.0.MinimumRateTurbo: UNSET dev.ndis.0.MinimumRate11Xr: UNSET dev.ndis.0.iqOverride: UNSET dev.ndis.0.iqLogCountMax: UNSET dev.ndis.0.iCoff: UNSET dev.ndis.0.qCoff: UNSET dev.ndis.0.modeCTS: UNSET dev.ndis.0.rateCTS: UNSET dev.ndis.0.shortSlotTime: UNSET dev.ndis.0.gdraft5: UNSET dev.ndis.0.protectionType: UNSET dev.ndis.0.Ssid2: UNSET dev.ndis.0.Ssid3: UNSET dev.ndis.0.XrFragThreshold: UNSET dev.ndis.0.atimWindow: UNSET dev.ndis.0.cfpDuration: UNSET dev.ndis.0.RD: UNSET dev.ndis.0.ignore11dBeacon: UNSET dev.ndis.0.quietDuration: UNSET dev.ndis.0.quietOffset: UNSET dev.ndis.0.quietAckCtsAllow: UNSET dev.ndis.0.extendedChanMode: UNSET dev.ndis.0.overRideTxPower: UNSET dev.ndis.0.enableFCC3: UNSET dev.ndis.0.capLinkSp: UNSET dev.ndis.0.keyLength0: UNSET dev.ndis.0.key0: UNSET dev.ndis.0.keyLength1: UNSET dev.ndis.0.key1: UNSET dev.ndis.0.keyLength2: UNSET dev.ndis.0.key2: UNSET dev.ndis.0.keyLength3: UNSET dev.ndis.0.key3: UNSET dev.ndis.0.uniqKeyLength: UNSET dev.ndis.0.uniqKey: UNSET dev.ndis.0.leapEnabled: UNSET dev.ndis.0.leapUserName: UNSET dev.ndis.0.leapUserPasswdLen: UNSET dev.ndis.0.leapUserPasswd: UNSET dev.ndis.0.leapTimeout: UNSET dev.ndis.0.CardCfgId: UNSET dev.ndis.0.authType: UNSET dev.ndis.0.authTypeUseOnly: UNSET dev.ndis.0.wpaEnabled: UNSET dev.ndis.0.mixedPrivacyAllow: UNSET dev.ndis.0.roamRssiA: UNSET dev.ndis
ipfw/dhclient conundrum
I have a circular conundrum involving the sequence of boot events that I'm trying to solve, and I'd like to know if any other users have found a solution to this, or what some suggestions may be. First, I'd like to note that I've been using 4-STABLE for a while, and I only recently started running 5-STABLE after my disk cratered. So I am still getting used to some of the new features of the system. The box in question uses dhclient to get an IP lease for the external link. The box must forward LAN traffic, and have a decent amount of protection, so ipfw natd and dhcpd services are also enabled. The conundrum I have is this: /etc/rc.d/ipfw needs to be run after /etc/rc.d/dhclient. This is due to the fact that I do not have a static IP lease, and my firewall script determines the external interface's ip address with ifconfig. However, if /etc/rc.d/dhclient runs before /etc/rc.d/ipfw, with the firewall at default-to-deny and no rules added to pass dhcp autoconfigure traffic, dhclient cannot acquire a lease. But to run the firewall script, dhclient needs to have acquired a lease so the rules make sense. But to run dhclient, ipfw needs to have run... et cetera ad nauseum. My interim fix is to add net.inet.ip.fw.enable=0 to sysctl.conf and remove the requirement of ipfw from the dhclient rc script. When rc takes off at boot time, the firewall is disabled and dhclient runs before ipfw. When ipfw runs, it enables the firewall sysctl and executes my firewall script, which gets sensible results since a lease for the external interface has been acquired. But then something screwy happens... sometime after netoptions runs (I'd include more detail if I had it), net.inet.ip.fw.enable is set back to zero... so my "fix" still requires operator intervention for the firewall and address translation to be enabled. I'd like to know a more sane way of correcting this behavior. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ndis wrapper around dwl-520 rev E
Hello everybody, I'm starting fresh with FreeBSD 5 after my 4_STABLE system's disk ate itself, and I've been fighting with wireless adapters for a little while. I'm wondering if anyone can help me make some sense of this problem: The machine has inside it a DLink DWL-520 card. It's a revision E, so it is not supported by wi (although wi will try to init and fail). Now that I am running FreeBSD 5.3, I've decided to give the ndisulator a shot. I had a hunch that having both ndis and wi vying for control of the device would be a badthing, so I recompiled my kernel _without_ device wi. I used the WinXP inf and sys files on the DLink install CD to make the ndis_driver_info.h. (note: the inf file gave me grief until I read somewhere that it needed a newline at the bottom to work correctly) I compiled if_ndis.ko and kldload'ed it. pciconf -l shows: [EMAIL PROTECTED]:0:0: class=0x06 card=0x80231043 chip=0x06911106 rev=0x02 hdr=0x00 [EMAIL PROTECTED]:1:0: class=0x060400 card=0x0080 chip=0x85981106 rev=0x00 hdr=0x01 [EMAIL PROTECTED]:4:0: class=0x060100 card=0x80231043 chip=0x06861106 rev=0x22 hdr=0x00 [EMAIL PROTECTED]:4:1: class=0x01018a card=0x chip=0x05711106 rev=0x10 hdr=0x00 [EMAIL PROTECTED]:4:2: class=0x0c0300 card=0x12340925 chip=0x30381106 rev=0x10 hdr=0x00 [EMAIL PROTECTED]:4:3: class=0x0c0300 card=0x12340925 chip=0x30381106 rev=0x10 hdr=0x00 [EMAIL PROTECTED]:4:4:class=0x06 card=0x chip=0x30571106 rev=0x30 hdr=0x00 [EMAIL PROTECTED]:10:0:class=0x028000 card=0x37001186 chip=0x38731260 rev=0x01 hdr=0x00 [EMAIL PROTECTED]:11:0: class=0x02 card=0x813910ec chip=0x813910ec rev=0x10 hdr=0x00 [EMAIL PROTECTED]:12:0: class=0x02 card=0x813910ec chip=0x813910ec rev=0x10 hdr=0x00 [EMAIL PROTECTED]:13:0: class=0x01 card=0x38699004 chip=0x38609004 rev=0x03 hdr=0x00 [EMAIL PROTECTED]:0:0: class=0x03 card=0x001a1002 chip=0x51441002 rev=0x00 hdr=0x00 The ndis driver seems to have initialized on pci0:10:0, but no ndis adapter shows in ifconfig -a. Troubled by this, I moved the driver object into /boot/kernel and added load_if_ndis="YES" to loader.conf, and rebooted. Maybe dmesg would tell me something important. It did: ndis0: mem 0xd700-0xd7000fff irq 5 at device 10.0 on pci0 can't re-use a leaf (BusType)! ndis0: NDIS API version: 5.1 ndis0: NDIS ERROR: c0001394 (unknown error) ndis0: NDIS NUMERRORS: 0 ndis0: init handler failed device_attach: ndis0 attach returned 6 So that's where I am. I don't know what to make of this dmesg output. Can anyone offer some insight? Thanks, Reid ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dri falling back to software in 4.8-stable
[CC'd for anyone who may need this resolution] Hi Carl, Yes, I actually did determine the resolution to the problem. Since I had been running the system since 4.7-release, I used the drm-kmod package in the ports tree to get the DRI support. An undocumented (as far as I can tell) change from 4.7-stable to 4.8-stable includes the drm kernel module in the kernel module sources, and the drm-kmod port is depricated. If you remove the drm-kmod startup script from /usr/local/etc/rc.d, optionaly pkg_delete the drm-kmod package, and rebuild your kernel with options drm and agp added, you should have hardware support upon loading the new kernel. I've browsed through the UPDATING file from my last source update and I've found no mention of this change between 4.7-release and 4.8-release. Does anyone know why? (my being dense is a perfectly valid reason) -Reid >Hi, > >I noticed your post on freebsd.questions about your problems in getting drm >acceleration to work under freebsd4.8-stable. You reported an error "Radeon >DRI driver expected DRM driver version 1.3.x or newer but got version 1.1.1". > >I'm having the same problem. Did you ever find a resolution? > >Thanks > > > >Dr. Glen Henshaw (202) 767-1196 >Naval Center for Space Technology [EMAIL PROTECTED] >U.S. Naval Research Laboratory > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
dri falling back to software in 4.8-stable
I've been noticing that GL performance has been really awful on my system lately, so I did some digging around. Here's a glxinfo: name of display: :0.0 libGL error: Radeon DRI driver expected DRM driver version 1.3.x or newer but got version 1.1.1 libGL error: InitDriver failed display: :0 screen: 0 direct rendering: No server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: Mesa project: www.mesa3d.org OpenGL renderer string: Mesa GLX Indirect OpenGL version string: 1.3 Mesa 4.0.4 OpenGL extensions: GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_texture_border_clamp, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3, GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_blend_color, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_lod_bias glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess Now, the drm driver works correctly, and the radeon drier is loading fine. After turning on verbose debugging output in the libGL library, I get this: libGL error: Radeon DRI driver expected DRM driver version 1.3.x or newer but got version 1.1.1 libGL error: InitDriver failed Any ideas? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"