Re: bf_next not NULL!
On Fri, Jul 29, 2016 at 01:43:20PM -0700, Adrian Chadd wrote: > oh god damint, wait. It's an AR9227, right? > > ok, please just twist my arm to figure out and commit the "am i deaf? > restart please" workaround I think i need for the AR9227/AR9287. Grr. > Consider your arm twisted. Glen signature.asc Description: PGP signature
Re: Intel 3160/7260/7265 driver
On Sun, May 10, 2015 at 09:48:51AM -0700, Rui Paulo wrote: I've ported the OpenBSD iwm driver and it's sort of working now: https://github.com/rpaulo/iwm Some issues: - scanning is sort of broken now, so you must set the channel with ifconfig - ultra debugging mode is activated, so expect a lot of logs. This still needs quite a bit of work before it can be part of FreeBSD, but this email is being sent over iwm. :-) I only have a 7265, so I'd like people with 3160 or 7260 to try it out. Thank you for working on this. The driver fails to attach on my system. pciconf(8) shows: iwm0@pci0:4:0:0: class=0x028000 card=0xc2708086 chip=0x08b28086 rev=0x83 hdr=0x00 vendor = 'Intel Corporation' class = network Unloading iwm(4) crashes the system (but unfortunately did not leave a crash dump). dmesg(8) output follows: wlan0: link state changed to UP iwm0: Intel Dual Band Wireless AC 7260 mem 0xe040-0xe0401fff irq 17 at device 0.0 on pci4 -iwm_prepare_card_hw -iwm_prepare_card_hw iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x9305a000 len 0x3 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x1ddff000 len 0x1000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x111fe000 len 0x1000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x9308a000 len 0x3200 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x9308e000 len 0x8000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x93096000 len 0x14400 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x931a2000 len 0x8000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x931aa000 len 0x14400 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x116bf000 len 0x8000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x116c7000 len 0x14400 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x117dc000 len 0x8000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x117e4000 len 0x14400 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x118f9000 len 0x8000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x11901000 len 0x14400 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x11a16000 len 0x8000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x11a1e000 len 0x14400 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x11b33000 len 0x8000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x11b3b000 len 0x14400 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x11c5 len 0x8000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x11c58000 len 0x14400 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x11d6d000 len 0x8000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x11d75000 len 0x14400 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x11e8a000 len 0x8000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x11e92000 len 0x14400 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x11fa7000 len 0x8000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x11faf000 len 0x8000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x11fb7000 len 0x8000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x11fbf000 len 0x8000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x11fc7000 len 0x8000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x11fcf000 len 0x8000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x11fd7000 len 0x8000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x11fdf000 len 0x8000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x11fe7000 len 0x8000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x11fef000 len 0x8000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x11ff7000 len 0x400 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x11ff8000 len 0xc iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x91fd2000 len 0x1000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x106e7000 len 0x1000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x170c000 len 0x1000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x170e000 len 0x1000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x91fb7000 len 0x1000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x170f000 len 0x1000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x106e8000 len 0x1000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0x106e9000 len 0x1000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0xf2c len 0x1000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0xf2c2000 len 0x1000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0xf2c4000 len 0x1000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr 0xf2c5000 len 0x1000 iwm_dma_map_addr error=0 nsegs=1 iwm_dma_map_addr addr
Re: disappearing ath(4)
On Sat, Dec 21, 2013 at 08:17:32AM -0800, Adrian Chadd wrote: The second possibility is that it's asleep - and no, NIC reads aren't showing 0xdeadc0de, 0xdeadbeef, etc. So no, it's not that. I didn't think of this when you first mentioned it, but I recently added this to rc.conf: performance_cx_lowest=C2 economy_cx_lowest=C2 Another thing I failed to mention, is the ath(4) is part of lagg(4), accompanied by alc(4). I'm half wondering if the *_cx_lowest is triggering something. The other half wonders if lagg(4) triggers something funky. He's also recently opened up his laptop and fiddled around. Trust me, I'm an engineer! he's going off to do some more testing. What can possibly go wrong? Glen pgptVxwVdGbHl.pgp Description: PGP signature
Re: disappearing ath(4)
I doubt lagg(4) is the issue. I've been doing that evil for years. I'll kill the *_cs_lowest, and see if that changes anything over the next few days. I'm 200% certain lagg(4) is not a factor, but if it continues, I'll disable that for SG. Glen On Sat, Dec 21, 2013 at 06:44:16PM -0800, Adrian Chadd wrote: Yeah. Try killing those. Leave it at c1 and no lagg. C2 and later may be triggering some weird stuff. Adrian On Dec 21, 2013 8:33 PM, Glen Barber g...@freebsd.org wrote: On Sat, Dec 21, 2013 at 08:17:32AM -0800, Adrian Chadd wrote: The second possibility is that it's asleep - and no, NIC reads aren't showing 0xdeadc0de, 0xdeadbeef, etc. So no, it's not that. I didn't think of this when you first mentioned it, but I recently added this to rc.conf: performance_cx_lowest=C2 economy_cx_lowest=C2 Another thing I failed to mention, is the ath(4) is part of lagg(4), accompanied by alc(4). I'm half wondering if the *_cx_lowest is triggering something. The other half wonders if lagg(4) triggers something funky. He's also recently opened up his laptop and fiddled around. Trust me, I'm an engineer! he's going off to do some more testing. What can possibly go wrong? Glen pgpU2upzRUJUc.pgp Description: PGP signature
disappearing ath(4)
Hi, Since last upgrade, it seems every few days (it seems roughly every 2 days), my ath(4) disappears, or more specifically, falls off enough to be unusable. Kernel is compiled with ATH_DEBUG and AH_DEBUG. athregs output before the device is unusable: - begin quoted text - CR 0004 RXDP 059c9960 CFG 0100 MIRT IER 0001 TIMT TXCFG00020085 RXCFG0005 MIBC TOPS 0008 RXNPTO 0008 TXNPTO 0010 RPGTO RPCNT001f MACMISC SPC_0 SPC_1 GTXTO GTTM 0008 CST 000f DMADBG0 DMADBG1 DMADBG2 12249249 DMADBG3 DMADBG4 DMADBG5 DMADBG6 001066b0 DMADBG7 DCM_Adeadbeef DCM_Ddeadbeef DCCFGdeadbeef CCFG deadbeef CCUCFG deadbeef CPC0 deadbeef CPC1 deadbeef CPC2 deadbeef CPC3 deadbeef CPCOVF deadbeef D_SIFS 0160 D_SLOT 018c D_EIFS 3e38 D_MISC D_SEQ0030 D_FPCTL D_TXPSE 0001 MAC_LED 0400 RC SCR 00ca05cb INTPEND 4400 SFR 03fd5991 PCICFG 0810 PCIEPMC 3a080400 SREV 000c12ff AHBMODE 001f IASYNCM 0002 ISYNCM 00023f60 SERDES a819 SERDES2 GPIOIO 00fff000 GPIOOE GPIOPOL GPIOIEV 00028020 GPIMUX1 GPIMUX2 GPOMUX1 GPOMUX2 GPOMUX3 badc0ffe OBS 0008 RTC_RC RTC_PLL 142c STA_ID0 3aa60454 STA_ID1 b880ea96 BSS_ID0 d952f690 BSS_ID1 0003cfff SLOTTIME 02d0 TIME_OUT 08400b00 RSSI_THR 0781 USEC 12e0002b BEACON CFP_PER TIMER0 TIMER1 TIMER2 TIMER3 CFP_DUR RXFILTER 0417 MCAST_0 84000804 MCAST_1 1040 DIAG_SW TSF_L32 14c389bc TSF_U32 0001 TST_ADAC DEF_ANT QOS_MASK 000fc78f SEQ_MASK 000f OBSERV2 OBSERV1 2880 LAST_TST 14c20180 NAV RTS_OK RTS_FAIL ACK_FAIL FCS_FAIL 0001 BEAC_CNT SLEEP1 1408 SLEEP2 1400 SLEEP3 BSSMSKL BSSMSKU TPC 003f3f3f TFCNTad69 RFCNT16f52865 RCCNT17ae2c66 CCCNT508c796c QUIET1 0002 QUIET2 0002 TSF_PARM NOACK0052 PHY_ERR QOS_CTRL 000100aa QOS_SEL 3210 MISCMODE 08f04814 FILTOFDM 0335 FILTCCK 0609 PHYCNT1 00bffe0c PHYCMSK1 0002 PHYCNT2 00bfff70 PHYCMSK2 0200 TXOPX00ff NXTTBTT 14c39000 NXTDBA NXTSWBA NXTCFP NXTHCF NXTDTIM 14c51400 NXTQUIET NXTNDP BCNPER 00019000 DBAPER 00019000 SWBAPER TIMPER 00019000 DTIMPER 00019000 QUIETPER NDPPER TIMERMOD 00100031 SLP32MOD 0010f400 SLP32WAK 0100 SLP32INC 0001e800 SLPCNT SLPMIB 2040MODE EXTRCCNT 38de4bf7 PCUTXBUF 0380 PHYTURBO 03c0 IMR: 81841df4 S0 030f000f S1 010f000f S2 008f S3 S4 ISR: 0008 S0 S1 S2 f200 S3 S4 Q_TXE Q_TXD Q_RDYTIMSHD Q_ONESHOTARM_SC Q_ONESHOTARM_CC Q[0] TXDP CBR RDYT MISC 0800 STS Q[1] TXDP CBR RDYT MISC 0800 STS Q[2] TXDP CBR RDYT MISC 0800 STS Q[3] TXDP 059c2940 CBR RDYT MISC 0800 STS Q[4] TXDP CBR RDYT MISC 0800 STS Q[5] TXDP CBR RDYT MISC 0800 STS Q[6] TXDP CBR RDYT MISC 0800 STS Q[7] TXDP CBR RDYT MISC 0800 STS Q[8] TXDP CBR RDYT 0100a800 MISC 0862 STS Q[9] TXDP CBR RDYT MISC 08a2 STS D[0] MASK 0001 IFS 007ffc0f RTRY 0008200a CHNT MISC 001102 D[1] MASK 0002 IFS 002ffc07 RTRY 0008200a CHNT 00100800 MISC 001102 D[2] MASK 0004 IFS 00203c07 RTRY 0008200a CHNT 00100bc0 MISC 001102 D[3] MASK 0008 IFS 00201c03 RTRY 0008200a CHNT 001005e0 MISC 001102 D[4] MASK 0010 IFS 002ffc0f RTRY 00082004 CHNT MISC 001002 D[5] MASK 0020 IFS 002ffc0f RTRY 00082004 CHNT MISC 001002 D[6] MASK 0040 IFS 002ffc0f RTRY 00082004 CHNT MISC 001002 D[7] MASK 0080 IFS 002ffc0f RTRY 00082004 CHNT MISC 001002 D[8] MASK 0100 IFS 002ffc0f RTRY 0008200a CHNT MISC 041102 D[9] MASK 0200 IFS 002ffc0f RTRY 0008200a CHNT MISC 251102 KEY[004] MAC 90:f6:52:d9:ff:cf AES-CCM eba4-77fa-f865-c6a4-31c4-daa3-2a5c-2c0a 9800 0007 9808 980c afe68e30 9810 fd14e000 9814 a65e7f6b 9818 00e0 981c 0001 9820
Re: disappearing ath(4)
On Fri, Dec 20, 2013 at 09:35:58PM -0500, Glen Barber wrote: Hi, Since last upgrade, it seems every few days (it seems roughly every 2 days), my ath(4) disappears, or more specifically, falls off enough to be unusable. Adrian pointed out that I forgot to include actually relevant information. Machine runs .0-CURRENT r258761, the wireless card info from dmesg.boot is: ath0: Atheros 9285 mem 0xde80-0xde80 irq 17 at device 0.0 on pci2 ath0: [HT] enabling HT modes ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 RX streams; 1 TX streams ath0: AR9285 mac 192.2 RF5133 phy 14.0 ath0: 2GHz radio: 0x; 5GHz radio: 0x00c0 Glen pgpJoQwIdWhvV.pgp Description: PGP signature
Re: request for help: MFC net80211 fixes from -HEAD to -10
On Thu, Nov 28, 2013 at 06:54:56PM -0800, Adrian Chadd wrote: I'd like a developer or two to organise the MFC of anything that's in net80211 on -HEAD back to -10 before 10.0-REL. There's a few critical fixes that need to go in but I just don't have the time to do it myself. :( Depending on what the fixes are, you're likely too late at this point. What are the fixes, specifically? Glen pgpI_JcI2qq1G.pgp Description: PGP signature
