From owner-freebsd-mobile Tue Mar 13 21:41:55 2001 Delivered-To: freebsd-mobile@freebsd.org Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E51337B718; Tue, 13 Mar 2001 21:41:45 -0800 (PST) (envelope-from bts@babbleon.org) Received: from babbleon.org ([66.26.250.181]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Wed, 14 Mar 2001 00:41:44 -0500 Message-ID: <3AAF047F.341981B2@babbleon.org> Date: Wed, 14 Mar 2001 00:41:20 -0500 From: The Babbler Organization: None to speak of X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile@freebsd.org Cc: freebsd-mobile@freebsd.org Subject: Re: Bridging with 3C589D-COMBO on 4.2-RELEASE? References: <3AAC4C03.13000DE@babbleon.org> <3AAC4E83.2C281B90@babbleon.org> <15021.46309.150521.925816@nomad.yogotech.com> <3AADBAB8.36039542@babbleon.org> <20010313104711.B6592@pir.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Peter Radcliffe wrote: > > The Babbler probably said: > > Perhaps all PCMCIA support under FreeBSD should be considered > > quasi-experimental or something, but I'm deliberately avoiding using > > anything but stock 4.2-RELEASSE in order to (hopefully) get maximum > > stability. > > PCMCIA under freebsd seems far more stable than Linux PCMCIA support > when _correctly_ _configured_. I've helped dozens of people get > wavelan support working at conferences and getting it as stable with > Linux requires the exact correct versions (and the only way to find > them is to test) of half a dozen things ... I haven't used WaveLANS, but every PCMCIA I ever stuck in my Linux box just worked. I've had to buy cards to get them to work with FreeBSD. My Linksys EtherFast Modem/Ethernet card is sitting a drawer in my desk because I finally gave up on it and bought a new (and more physically awkward) card for FreeBSD. You can search for old postings of my back in January or so for the saga on *that*. Similarly, I could *never* get two identical cards to work on my gateway machine; I finally bought a card to make FreeBSD happy. With Linux it just worked. Easy. To say the least, then, my experience does not concord with yours in this regard. > > For example, it froze both last night and tonight while I was trying to > > get vmware networking set up properly. > > vmware messes with things at a pretty low level and isn't designed for > FreeBSD. It's going to cause problems. Having said that, once I got it > set up properly (you did read the FreeBSD readme, didn't you ?) it > hasn't crashed the host OS on my machine in a long time. I read the FreeBSD readme. And I've had a nubmer of posting in the emultors group as I got things working there, too. The bridging would never work for me, but my final conclusion is that my card doesn't work with bridging, I guess. Only some cards do. (It says *that* in the handbook and the bridge man page.) > > But it's not just that; my gateway/firewall just locks up with the > > PCMCIA light stuck on about every couple of weeks. > > I would assume you have a misconfiguration or a hardware problem. > I've had freebsd boxes doing routing/filtering/pcmcia up for > _months_ with no problems. PCMCIA-based laptops or desktops? > > And making it all especially bad is that I've FreeBSD lose file contents > > (revert to zero length) after rebooting, even on files that hadn't > > actually been updated any time close to when the lockup occured. > > Never seen that in my last few years of freebsd use. Happened to me twice within days of my install. Both times it was "cal.vcs," for what it's worth. That's the calendar database for korganize, which *is* loaded, but would have had no reason to be writing to disk when I crashed. I never lost any files under Linux except once when I had a physical disk failure. > > (In fairness, I should note that Linux PCMCIA support appears to be > > superior to everybody else's. It's certainly superior to Windows as > > well as FreeBSD.) > > Can't disagree strongly enough. Well, as I said before, that's my experience. Probably depends on the network cards one uses and such. > > Anyway, any suggestions for determining the source of such crashes. For > > the fully-configured system, since the lockups happen only every couple > > of weeks, it's not really feasible to leave kernel tracing permanently > > on or anything like that. And these "crashes" of which I speak are > > system lockups, not kernel panics--there's no recovery possible becuase > > it locks up tight as a drum and I have to power off. Nor is this just > > an X display problem, for it also happens to my gateway/firewall, which > > doesn't even have X installed. > > > > How would you deal with such problems? > > Double and triple check for any irq/memory problems and then start > using DDB and DIAGNOSTIC. It's the only sane way to debug hard hangs. I did *lots* of checking for irq/memory problems on the gateway, believe you me. As for the "man" laptop computer, so far all crashes have involved configuration, though frequently at the bridge/ethernet layer rather than the hardware layer. Frequently they've involved poppping out or in a PCMCIA card while there's a daemon running that expects to talk to it. This is unfriendly to the O/S, but Linux seemed to handle such situations with more alactrity. > using DDB and DIAGNOSTIC. It's the only sane way to debug hard hangs. No manual entry for diagnostic. Also, I did a "make search" on ports. No "diagnostic" there, either. As for ddb, what you do, leave it up for two weeks waiting for the elusive crash? Wouldn't that have a severe impact on performance at least? Besides, when it hangs, it *hangs*. It won't even respond to keyboard input, not even CTL-ALT-DEL or ALT-F2. How would I use an interactive debugger in this context? Use the remote debugging? To do that, do I need a null modem cable? Not to mention that I don't *have* a desktop Linux/FreeBSD machine (though perhaps there's a gdb for Windows . . .) that could keep the gdb session up for that long. I'm not trying to difficult; I'm really ignorant, never having had much cause to do kernel debugging before. (I was once upon a time working on a Linux device driver for . . . heck, I forget what . . . but it was a while ago and I did it the old-fashioned way, with kernel logging calls.) > > P. > > -- > pir pir@pir.net pir@net.tufts.edu > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-mobile" in the body of the message -- "Brian, the man from babble-on" bts@babbleon.org Brian T. Schellenberger http://www.babbleon.org Support http://www.eff.org. Support decss defendents. Support http://www.programming-freedom.org. Boycott amazon.com. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message