Wireless card problem in 4.9
lbecker
I had a 4.8 box with a D-LINK wireless network card (model DWL-650 PCCARD in a
DLINK PCI to PCCARD adapter) and it was working well (no problems).
After updating to 4.9-RELEASE I notice that after awhile (less than a day) the
box stops responding over the network. When I log onto the console, there is no
network connectivity (i.e can't ping other boxes on the network, nslookup
doesn't work, etc), and I reboot and the network connectivity is restored.
I looked in /var/log/messages and see the following entry:
Nov 4 06:56:46 beastie /kernel: wi0: timeout in wi_seek to fc80/0; last status
ffff
Has anyone else seen this problem? after a reboot the network is up, but after I
go to work for 8-10 hours and come home the networking is down.
Any other messages, log files, or troubleshooting techniques that would help
debugging this problem?
thanks in advance.
dmesg out is appended below:
Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 4.9-RELEASE #0: Sat Nov 1 07:55:15 EST 2003
nos...@nospam.com:/usr/obj/usr/src/sys/BEASTIE
Timecounter "i8254" frequency 1193182 Hz
CPU: AMD-K6(tm) 3D processor (451.02-MHz 586-class CPU)
Origin = "AuthenticAMD" Id = 0x58c Stepping = 12
Features=0x8021bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,PGE,MMX>
AMD Features=0x80000800<SYSCALL,3DNow!>
real memory = 335527936 (327664K bytes)
avail memory = 320806912 (313288K bytes)
Preloaded elf kernel "kernel" at 0xc0529000.
K6-family MTRR support enabled (2 registers)
md0: Malloc disk
Using $PIR table, 8 entries at 0xc00f0d00
npx0: <math processor> on motherboard
npx0: INT 16 interface
pcib0: <AcerLabs M1541 (Aladdin-V) PCI host bridge> on motherboard
pci0: <PCI bus> on pcib0
agp0: <Ali M1541 host to AGP bridge> mem 0xe0000000-0xe3ffffff at device 0.0 on
pci0
pcib1: <AcerLabs M5243 PCI-PCI bridge> at device 1.0 on pci0
pci1: <PCI bus> on pcib1
pci1: <Matrox MGA G400 AGP graphics accelerator> at 0.0 irq 11
ohci0: <AcerLabs M5237 (Aladdin-V) USB controller> mem 0xde800000-0xde800fff irq
10 at device 2.0 on pci0
usb0: OHCI version 1.0, legacy support
usb0: <AcerLabs M5237 (Aladdin-V) USB controller> on ohci0
usb0: USB revision 1.0
uhub0: AcerLabs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
ulpt0: Hewlett-Packard DeskJet 830C, rev 1.00/1.00, addr 2, iclass 7/1
chip0: <AcerLabs M15x3 Power Management Unit> at device 3.0 on pci0
isab0: <AcerLabs M1533 portable PCI-ISA bridge> at device 7.0 on pci0
isa0: <ISA bus> on isab0
pcic0: <Ricoh RL5C475 PCI-CardBus Bridge> irq 5 at device 10.0 on pci0
pcic0: PCI Memory allocated: 0x88000000
pccard0: <PC Card 16-bit bus (classic)> on pcic0
atapci0: <AcerLabs Aladdin ATA33 controller> port 0xd800-0xd80f irq 0 at device
15.0 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
orm0: <Option ROM> at iomem 0xc0000-0xc8fff on isa0
pmtimer0 on isa0
fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: model IntelliMouse, device ID 3
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/7 bytes threshold
ppbus0: IEEE1284 device found /NIBBLE/ECP
Probing for PnP devices on ppbus0:
ppbus0: <Hewlett-Packard HP LaserJet 6MP> PJL,MLC,PCLXL,PCL,POSTSCRIPT
plip0: <PLIP network interface> on ppbus0
lpt0: <Printer> on ppbus0
lpt0: Interrupt-driven port
ppi0: <Parallel I/O> on ppbus0
ad0: 13029MB <Maxtor 91366U4> [26473/16/63] at ata0-master UDMA33
ad1: 38166MB <WDC WD400BB-32CAA0> [77545/16/63] at ata0-slave UDMA33
pccard: card inserted, slot 0
Mounting root from ufs:/dev/ad0s1a
wi0 at port 0x240-0x27f irq 5 slot 0 on pccard0
wi0: 802.11 address: 00:05:5d:f1:09:01
wi0: using RF:PRISM2 MAC:HFA3841 CARD:HWB3163-SST-flash
wi0: Intersil Firmware: Primary 0.03.00, Station 1.03.04
George Reitsma
4.8 STABLE. The card just stopped responding after about 12 hours. I've
replaced the card by a 3COM, cause I thought it was a hardware failure.
Don't know any other solution
lbecker
wrote:
>lbecker wrote:
<problem description snipped>
>> Has anyone else seen this problem? after a reboot the network is up, but after I
>> go to work for 8-10 hours and come home the networking is down.
>>
>> Any other messages, log files, or troubleshooting techniques that would help
>> debugging this problem?
>>
>> thanks in advance.
>>
<snipped dmesg>
>>
>Yes, I've seen exactly the same card and excactly the same problem on
>4.8 STABLE. The card just stopped responding after about 12 hours. I've
>replaced the card by a 3COM, cause I thought it was a hardware failure.
>
>Don't know any other solution
Thanks. It seems to be software related or a big coincidence. That is, it
worked fine for me under 4.8-RELEASE and as soon as I went to 4.9 is started
acting up. I guess I need to compare some of the source code to see if anything
changed.... any ideas on what source files or driver code might be involved..
I'll search around for wi driver information and see if anything changed in the
source from 4.8
- lb
lbecker
>Thanks. It seems to be software related or a big coincidence. That is, it
>worked fine for me under 4.8-RELEASE and as soon as I went to 4.9 is started
>acting up. I guess I need to compare some of the source code to see if anything
>changed.... any ideas on what source files or driver code might be involved..
>I'll search around for wi driver information and see if anything changed in the
>source from 4.8
>
following up on my own post...
I found the directory for the driver and it looks like 3 files changed recently
with the upgrade to 4.9
if_wi.c
if_wi_pci.c
if_wivar.h
all changed on on Oct 29, the day I cvsup'ed the source.
%pwd
/usr/src/sys/dev/wi
%ll
total 182
-rw-r--r-- 1 root wheel 22231 Aug 2 2002 if_wavelan_ieee.h
-rw-r--r-- 1 root wheel 79728 Oct 29 15:48 if_wi.c
-rw-r--r-- 1 root wheel 6351 Aug 2 2002 if_wi_pccard.c
-rw-r--r-- 1 root wheel 7615 Oct 29 15:48 if_wi_pci.c
-rw-r--r-- 1 root wheel 19086 Aug 2 2002 if_wireg.h
-rw-r--r-- 1 root wheel 7082 Oct 29 15:48 if_wivar.h
-rw-r--r-- 1 root wheel 32166 Aug 2 2002 wi_hostap.c
-rw-r--r-- 1 root wheel 4416 Aug 2 2002 wi_hostap.h
I looked at the RELEASE NOTES at
http://www.freebsd.org/releases/4.9R/relnotes-i386.html
and it says under Network Interface Support that:
" The suspend/resume support for the wi(4) driver now works correctly when
the device is configured down."
Hmmmmm. Interesting... I wonder what "configured down" actually means...
Anyway I can do a diff with the 4.8-RELEASE version of those files to see what
code actually changed... I wonder if I can revert to the 4.8-RELEASE version of
the driver and see if that works better? any easy way to do that?
lbecker
>Anyway I can do a diff with the 4.8-RELEASE version of those files to see what
>code actually changed...
looks like there was just a new change to the if_wi.c file a few hours ago:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/wi/if_wi.c
this is the first time I used the nifty colored diff tool on the freebsd site...
very handy:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/wi/if_wi.c.diff?r1=1.154&r2=1.155&f=h
jpd
[snip]
> following up on my own post...
>
> I found the directory for the driver and it looks like 3 files changed
> recently
> with the upgrade to 4.9
>
> if_wi.c
> if_wi_pci.c
> if_wivar.h
>
> all changed on on Oct 29, the day I cvsup'ed the source.
Then you might have a partially updated tree. Do update again and see
if that stops the breakage. If it doesn't, maybe it's time for a PR.
[snip]
> Hmmmmm. Interesting... I wonder what "configured down" actually means...
# ifconfig wi0 down
Meaning that it's there but not active. Network devices default to down
if there's no ip assigned. Rather, if -on a marked down interface- you
# ifconfig wi0 ip.ad.re.ss/mask
there's an `up' implied:
# ifconfig wi0 ip.ad.re.ss/mask up
This, and more detail, can be found in ifconfig(8).
> Anyway I can do a diff with the 4.8-RELEASE version of those files to see
> what
> code actually changed... I wonder if I can revert to the 4.8-RELEASE version
> of
> the driver and see if that works better? any easy way to do that?
Change the tag back to RELENG_4_8 and cvsup again?
Or only checkout that bit of the tree using cvs. I don't think you want
to go there, though. Better see if a re-cvsup of the 4.9 branch solves
things.
--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
lbecker
wrote:
>Yes, I've seen exactly the same card and excactly the same problem on
>4.8 STABLE. The card just stopped responding after about 12 hours. I've
>replaced the card by a 3COM, cause I thought it was a hardware failure.
>
>Don't know any other solution
Today before I went to work, I logged into the console and entered a ping once
per minute command (ping -i 60) and the interface was still up and working when
I came home..
that leads me to believe it is powering down or going to sleep or something
after inactivity and doesn't "wake up"...