hard lock on ifconfig wi0 up

[reuteler]

i'm wondering if anyone has any ideas here. i have a lex twister (a via c7) with a mini-pci 802.11 card installed (an intersil prism chipset, shows up as wi0). it's detected and shows up in ifconfig but when i do an ifconfig wi0 up it locks up the system. same for a linksys PCI (not mini-pci) card (ral driver). both these cards worked fine in a soekris box so it seems to be an issue w/ the twister? any ideas?

reuteler@panic,0$ ifconfig wi0
wi0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:02:6f:4a:d0:24
media: IEEE802.11 autoselect (none)
ieee80211: nwid IBSS chan 1 bssid 44:44:44:44:44:44 -13dBm (auto)
reuteler@panic,0$

here's the dmesg

OpenBSD 4.3 (GENERIC) #698: Wed Mar 12 11:07:05 MDT 2008
deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: VIA Esther processor 1000MHz ("CentaurHauls" 686-class) 1.01 GHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,P GE,CMOV,PAT,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,TM,SBF,S SE3,EST,TM2
cpu0: RNG AES AES-CTR SHA1 SHA256 RSA
real mem = 1005023232 (958MB)
avail mem = 963633152 (918MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 12/05/06, BIOS32 rev. 0 @ 0xf9ee0, SMBIOS rev. 2.3 @ 0xf0800 (33 entries)
bios0: vendor Phoenix Technologies, LTD version "6.00 PG" date 12/05/2006
apm0 at bios0: Power Management spec V1.2 (slowidle)
apm0: AC on, battery charge unknown
acpi at bios0 function 0x0 not configured
pcibios0 at bios0: rev 2.1 @ 0xf0000/0xd964
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfd860/240 (13 entries)
pcibios0: bad IRQ table checksum
pcibios0: PCI BIOS has 14 Interrupt Routing table entries
pcibios0: PCI Exclusive IRQs: 3 5 7 10 11
pcibios0: PCI Interrupt Router at 000:17:0 ("VIA VT8237 ISA" rev 0x00)
pcibios0: PCI bus #3 is the last bus
bios0: ROM list: 0xc0000/0xfc00
cpu0 at mainbus0
cpu0: unknown Enhanced SpeedStep CPU, msr 0x08100a1308000a13
cpu0: using only highest and lowest power states
cpu0: Enhanced SpeedStep 1000 MHz (1004 mV): speeds: 1000, 800 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "VIA CN700 Host" rev 0x00
agp0 at pchb0: v3, aperture at 0xe0000000, size 0x10000000
pchb1 at pci0 dev 0 function 1 "VIA CN700 Host" rev 0x00
pchb2 at pci0 dev 0 function 2 "VIA CN700 Host" rev 0x00
pchb3 at pci0 dev 0 function 3 "VIA PT890 Host" rev 0x00
pchb4 at pci0 dev 0 function 4 "VIA CN700 Host" rev 0x00
pchb5 at pci0 dev 0 function 7 "VIA CN700 Host" rev 0x00
ppb0 at pci0 dev 1 function 0 "VIA VT8377 AGP" rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "VIA S3 Unichrome PRO IGP" rev 0x01
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
em0 at pci0 dev 5 function 0 "Intel PRO/1000MT (82541GI)" rev 0x05: irq 10, address 00:30:18:4a:a4:ac
em1 at pci0 dev 6 function 0 "Intel PRO/1000MT (82541GI)" rev 0x05: irq 11, address 00:30:18:4a:a4:ad
em2 at pci0 dev 7 function 0 "Intel PRO/1000MT (82541GI)" rev 0x05: irq 7, address 00:30:18:4a:a4:ae
em3 at pci0 dev 8 function 0 "Intel PRO/1000MT (82541GI)" rev 0x05: irq 5, address 00:30:18:4a:a4:af
wi0 at pci0 dev 9 function 0 "Intersil PRISM2.5" rev 0x01: irq 3
wi0: PRISM2.5 ISL3874A(Mini-PCI) (0x8013), Firmware 1.1.0 (primary), 1.4.9 (station), address 00:02:6f:4a:d0:24
cbb0 at pci0 dev 10 function 0 "Ricoh 5C476 CardBus" rev 0x8b: irq 11
cbb1 at pci0 dev 10 function 1 "Ricoh 5C476 CardBus" rev 0x8b: irq 10
pciide0 at pci0 dev 15 function 0 "VIA VT6420 SATA" rev 0x80: DMA
pciide0: using irq 11 for native-PCI interrupt
wd0 at pciide0 channel 0 drive 0: <ST98823AS>
wd0: 16-sector PIO, LBA48, 76319MB, 156301488 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
pciide1 at pci0 dev 15 function 1 "VIA VT82C571 IDE" rev 0x06: ATA133, channel 0 configured to compatibility, channel 1 con
figured to compatibility
pciide1: channel 0 disabled (no drives)
pciide1: channel 1 disabled (no drives)
uhci0 at pci0 dev 16 function 0 "VIA VT83C572 USB" rev 0x81: irq 10
uhci1 at pci0 dev 16 function 1 "VIA VT83C572 USB" rev 0x81: irq 10
uhci2 at pci0 dev 16 function 2 "VIA VT83C572 USB" rev 0x81: irq 11
uhci3 at pci0 dev 16 function 3 "VIA VT83C572 USB" rev 0x81: irq 11
ehci0 at pci0 dev 16 function 4 "VIA VT6202 USB" rev 0x86: irq 7
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "VIA EHCI root hub" rev 2.00/1.00 addr 1
viapm0 at pci0 dev 17 function 0 "VIA VT8237 ISA" rev 0x00
iic0 at viapm0
spdmem0 at iic0 addr 0x50: 1GB DDR2 SDRAM ECC PC2-4200CL3
auvia0 at pci0 dev 17 function 5 "VIA VT8233 AC97" rev 0x60: irq 7
ac97: codec id 0x56494161 (VIA Technologies VT1612A)
ac97: codec features headphone, 18 bit DAC, 18 bit ADC, KS Waves 3D
audio0 at auvia0
cardslot0 at cbb0 slot 0 flags 0
cardbus0 at cardslot0: bus 2 device 0 cacheline 0x0, lattimer 0x20
pcmcia0 at cardslot0
cardslot1 at cbb1 slot 1 flags 0
cardbus1 at cardslot1: bus 3 device 0 cacheline 0x0, lattimer 0x20
pcmcia1 at cardslot1
usb1 at uhci0: USB revision 1.0
uhub1 at usb1 "VIA UHCI root hub" rev 1.00/1.00 addr 1
usb2 at uhci1: USB revision 1.0
uhub2 at usb2 "VIA UHCI root hub" rev 1.00/1.00 addr 1
usb3 at uhci2: USB revision 1.0
uhub3 at usb3 "VIA UHCI root hub" rev 1.00/1.00 addr 1
usb4 at uhci3: USB revision 1.0
uhub4 at usb4 "VIA UHCI root hub" rev 1.00/1.00 addr 1
isa0 at mainbus0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
midi0 at pcppi0: <PC speaker>
spkr0 at pcppi0
viasio0 at isa0 port 0x2e/2: VT1211 rev 0x02, HM, WDG not activated
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
biomask ffc5 netmask ffed ttymask ffef
softraid0 at root
root on wd0a swap on wd0b dump on wd0b

[jggimi]

Originally Posted by reuteler

...any ideas?...

Sure. You're right, it could be the "twister" since multiple cards cause a freeze. But it could be anything. I have two suggestions:

1. You might be able to use ddb(4) to determine where your system is hanging. This requires both the sysctl ddb.console set to 1, and the ability to use the ddb debugger.

2. You might consider updating firmware on that NIC. Searching the misc@ archives for the ISL3874A had several threads that discussed firmware. Those threads were from 2006 or earlier, and all of them seemed to talk about firmware newer than yours, which is at 1.4.9. Of course, this might not help since you seem to have the same problem with a ral(4) card. Of course, if *it* has out-of-date firmware too ....

[BSDfan666]

According to the man page, wi(4) doesn't have an externally located firmware, it's stored on the device in a ROM.

[jggimi]

Correct. One has to use the manufacturer's firmware loaders. Typically, these are MS DOS or MS Windows applications.

[reuteler]

Originally Posted by jggimi

Sure. You're right, it could be the "twister" since multiple cards cause a freeze. But it could be anything. I have two suggestions:

yea.. i never tried both cards at once, tho. so it's not that.

1. You might be able to use ddb(4) to determine where your system is hanging. This requires both the sysctl ddb.console set to 1, and the ability to use the ddb debugger.

i'm a developer, so i uhh, know my way around debuggers (cough) and i'd actually like to try this one.

2. You might consider updating firmware on that NIC. Searching the misc@ archives for the ISL3874A had several threads that discussed firmware. Those threads were from 2006 or earlier, and all of them seemed to talk about firmware newer than yours, which is at 1.4.9. Of course, this might not help since you seem to have the same problem with a ral(4) card. Of course, if *it* has out-of-date firmware too ....

i upgraded..

wi0 at pci0 dev 9 function 0 "Intersil PRISM2.5" rev 0x01: irq 3
wi0: PRISM2.5 ISL3874A(Mini-PCI) (0x8013), Firmware 1.1.1 (primary), 1.8.2 (station), address 00:02:6f:4a:d0:24

.. same problem. i tried a linux live cd and that didn't seem to have any problem with it. so it appears to be an openbsd issue. i'd like to try freebsd but the cd won't boot at all. not sure what's up with that. but i didn't push the issue.

[jggimi]

Originally Posted by reuteler

yea.. i never tried both cards at once, tho. so it's not that...

No, I meant two different cards have the same symptom.

Seems like backtracing in ddb is the way to go.

[reuteler]

Originally Posted by jggimi

No, I meant two different cards have the same symptom.

Seems like backtracing in ddb is the way to go.

duh, sorry. well, the kernel doesn't panic. it's stuck in la la land. i broke into the debugger during the hang but just kind of wandered around aimlessly not knowing what i'm really looking for.

root@panic,0# ifconfig wi0
wi0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:02:6f:4a:d0:24
media: IEEE802.11 autoselect (none)
ieee80211: nwid IBSS chan 1 bssid 44:44:44:44:44:44 -8dBm (auto)
root@panic,0# ifconfig wi0 up
root@panic,0# Stopped at Debugger+0x4: leave
ddb>
Stopped at Debugger+0x4: leave
ddb> next
After 1 instructions (0 loads, 0 stores),
Stopped at Debugger+0x5: ret
ddb> next
After 88 instructions (0 loads, 0 stores),
Stopped at comintr+0x4b: ret
ddb> next
After 2708 instructions (0 loads, 0 stores),
Stopped at Xdoreti+0x7d: iret
ddb> next
After 6861969 instructions (0 loads, 0 stores),
Stopped at Debugger+0x5: ret
ddb> s
Stopped at comintr+0x9f: jmp comintr+0x58
ddb> s
Stopped at comintr+0x58: movl 0xffffffec(%ebp),%ebx
ddb> s
Stopped at comintr+0x5b: testl %ebx,%ebx
ddb> s
Stopped at comintr+0x5d: jnz comintr+0x280
ddb> s
Stopped at comintr+0x63: movl 0xffffffe8(%ebp),%edx
ddb> s
Stopped at comintr+0x66: addl $0x5,%edx
ddb> s
Stopped at comintr+0x69: inb %dx,%al
ddb> s
Stopped at comintr+0x6a: movb %al,0xffffffe7(%ebp)
ddb> s
Stopped at comintr+0x6d: testb $0x1f,0xffffffe7(%ebp)
ddb> s
Stopped at comintr+0x71: jz comintr+0xd4
ddb> s
Stopped at comintr+0xd4: movl 0xffffffec(%ebp),%eax
ddb> s
Stopped at comintr+0xd7: testl %eax,%eax
ddb> s
Stopped at comintr+0xd9: jnz comintr+0x274
ddb> s
Stopped at comintr+0xdf: movl 0xffffffe8(%ebp),%edx
ddb> s
Stopped at comintr+0xe2: addl $0x6,%edx
ddb> s
Stopped at comintr+0xe5: inb %dx,%al
ddb> s
Stopped at comintr+0xe6: movb %al,%bl
ddb> s
Stopped at comintr+0xe8: movl 0x8(%ebp),%ecx
ddb> s
Stopped at comintr+0xeb: movb 0x94(%ecx),%dl
ddb> s
Stopped at comintr+0xf1: movb %bl,%al
ddb> s
Stopped at comintr+0xf3: xorl %edx,%eax
ddb> s
Stopped at comintr+0xf5: movzbl %bl,%ecx
ddb> s
Stopped at comintr+0xf8: movl %eax,%esi
ddb> s
Stopped at comintr+0xfa: movl %ecx,%eax
ddb> s
Stopped at comintr+0xfc: subl $0xc,%esp
ddb> s
Stopped at comintr+0xff: andl $0x80,%eax
ddb> s
Stopped at comintr+0x104: movzbl %dl,%edx
ddb> s
Stopped at comintr+0x107: pushl %eax
ddb> s
Stopped at comintr+0x108: movl %edx,%eax
ddb> s
Stopped at comintr+0x10a: andl $0x80,%eax
ddb> s
Stopped at comintr+0x10f: pushl %eax
ddb> s
Stopped at comintr+0x110: andl $0x10,%ecx
ddb> s
Stopped at comintr+0x113: pushl %ecx
ddb> s
Stopped at comintr+0x114: andl $0x10,%edx
ddb> show registers
ds 0x10
es 0x10
fs 0x58
gs 0x10
edi 0x161
esi 0x300
ebp 0xde159e5c end+0xd8c0d88
ebx 0xb0
edx 0xb0
ecx 0x10
eax 0x80
eip 0xd05d1a74 comintr+0x114
cs 0x50
eflags 0x202
esp 0xde159e1c end+0xd8c0d48
ss 0xde150010 end+0xd8b6f3c
comintr+0x114: andl $0x10,%edx
ddb> match
After 54 instructions (0 loads, 0 stores),
Stopped at comintr+0x4b: ret
ddb> match
After 2780 instructions (0 loads, 0 stores),
Stopped at Xdoreti+0x7d: iret
ddb> match
After 656 instructions (0 loads, 0 stores),
Stopped at alltraps+0x79: iret
ddb> match
After 21 instructions (0 loads, 0 stores),
Stopped at kdb_trap+0x37: ret
ddb> match
uvm_fault(0xd07e9980, 0x0, 0, 1) -> e
kernel: page fault trap, code=0
uvm_fault(0xd07e9980, 0x0, 0, 1) -> e
kernel: page fault trap, code=0
uvm_fault(0xd07e9980, 0x0, 0, 1) -> e
kernel: page fault trap, code=0
uvm_fault(0xd07e9980, 0x0, 0, 1) -> e

ad nauseum.

[reuteler]

oops.. forgot the trace

root@panic,0# ifconfig wi0 up
root@panic,0# Stopped at Debugger+0x4: leave
ddb> trace
Debugger(d1894f40,d0201f6e,de159e60,f95cec3a,3f8) at Debugger+0x4
comintr(d1893000) at comintr+0x9f
Xrecurse_legacy4() at Xrecurse_legacy4+0xad
--- interrupt ---
Xhold_legacy5() at Xhold_legacy5+0x18
--- interrupt ---
viac3_rnd(d08090f0,10,d1894f00,d0898cd4,0) at viac3_rnd+0x21
softclock(58,10,10,10,d794c2b0) at softclock+0x22c
Bad frame pointer: 0xde159f28

[reuteler]

well, this blurb in /usr/src/sys/arch/i386/i386/via.c before viac3_rnd is interesting

511 /*
512 * Note, the VIA C3 Nehemiah provides 4 internal 8-byte buffers, which
513 * store random data, and can be accessed a lot quicker than waiting
514 * for new data to be generated. As we are using every 8th bit only
515 * due to whitening. Since the RNG generates in excess of 21KB/s at
516 * its worst, collecting 64 bytes worth of entropy should not affect
517 * things significantly.
518 *
519 * Note, due to some weirdness in the RNG, we need at least 7 bytes
520 * extra on the end of our buffer. Also, there is an outside chance
521 * that the VIA RNG can "wedge", as the generated bit-rate is variable.
522 * We could do all sorts of startup testing and things, but
523 * frankly, I don't really see the point. If the RNG wedges, then the
524 * chances of you having a defective CPU are very high. Let it wedge.
525 *
526 * Adding to the whole confusion, in order to access the RNG, we need
527 * to have FXSR support enabled, and the correct FPU enable bits must
528 * be there to enable the FPU in kernel. It would be nice if all this
529 * mumbo-jumbo was not needed in order to use the RNG. Oh well, life
530 * does go on...
531 */

[jggimi]

There's been no changes to via.c since 4.3-release.

Can you run your diagnostics without X running? X seems to be getting in the way.

[reuteler]

Originally Posted by jggimi

There's been no changes to via.c since 4.3-release.

Can you run your diagnostics without X running? X seems to be getting in the way.

yea, that's the strange bit. i don't have X running. i'm not sure where that's coming from. it's installed but ..

reuteler@panic,2$ ls -ld /usr/X11R6/
d--------- 7 root wheel 512 Apr 17 06:51 /usr/X11R6//

.. turned off.

[jggimi]

Never mind. It's not X, it's a symbol in the kernel. A little grepping found Xrecurse_legacy4 in sys/arch/i386/i386/vector.s

That particular hunk of code deals with suspended interrupts.

This is a problem worth reporting to misc@.