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?

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 ....

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.

Quote:

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.

Quote:

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 ....

.. 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.

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 */