From owner-freebsd-mobile@FreeBSD.ORG Sun Jan 30 23:56:10 2005 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62A5516A4CE for ; Sun, 30 Jan 2005 23:56:10 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4E1343D39 for ; Sun, 30 Jan 2005 23:56:09 +0000 (GMT) (envelope-from astrodog@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so619506wra for ; Sun, 30 Jan 2005 15:56:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=HGZ5/j6cbHbCxyIHODWxcueRucq22+U5ROCPxNvKJ7XGyEu1dMFC+uF0653ErI7wO0FR8hOjNLQB7STOF+Oxu3jinocj5gk74+k7IN7edlAze6ujlEA5W94TTNxlAbaQztUi3l7Y5cWWrLiqSxJEyG15y+kK7jaiEmtFsTvOr+s= Received: by 10.54.41.50 with SMTP id o50mr95394wro; Sun, 30 Jan 2005 15:56:09 -0800 (PST) Received: by 10.54.40.65 with HTTP; Sun, 30 Jan 2005 15:56:09 -0800 (PST) Message-ID: <2fd864e050130155626f43786@mail.gmail.com> Date: Sun, 30 Jan 2005 15:56:09 -0800 From: Astrodog To: freebsd-mobile@freebsd.org In-Reply-To: <2fd864e0501301555588701dd@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41F692C5.40908@att.net> <20050125.114855.74697625.imp@harmony.village.org> <41F6C64B.3040700@att.net> <20050125.153403.116353342.imp@bsdimp.com> <41FD18DA.2000503@att.net> <2fd864e050130141467f0975c@mail.gmail.com> <41FD6360.9080609@att.net> <2fd864e0501301555588701dd@mail.gmail.com> Subject: 3Com Megahertz 3CXM756 PCMCIA modem on 5.3 X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Astrodog List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 23:56:10 -0000 Sorry. Ended up sending it only to Duane. Oops! ---------- Forwarded message ---------- From: Astrodog Date: Sun, 30 Jan 2005 15:55:31 -0800 Subject: Re: 3Com Megahertz 3CXM756 PCMCIA modem on 5.3 To: Duane Winner On Sun, 30 Jan 2005 17:44:48 -0500, Duane Winner wrote: > Astrodog wrote: > > >On Sun, 30 Jan 2005 12:26:50 -0500, Duane Winner wrote: > > > > > >>M. Warner Losh wrote: > >> > >> > >> > >>>In message: <41F6C64B.3040700@att.net> > >>> Duane Winner writes: > >>>: Warner Losh wrote: > >>>: > >>>: >>Thanks! That would be great. At least I know it's not just me. > >>>: >> > >>>: >> > >>>: > > >>>: >I've updated what I think is the fix to RELENG_5, so please test and > >>>: >let me know. > >>>: > > >>>: > > >>>: > > >>>: That did the trick. I took one of my other T30's and changed my cvs tag > >>>: from RELENG_5_3 to RELENG_5, cvsup'd, buildword and buildkernel, and I > >>>: was able to dial out. > >>>: > >>>: I get this now when inserting the card: > >>>: > >>>: pccard1: Allocation failed for cfe 32 > >>>: sio4: <3Com Megahertz 3CXM756/3CCM756> at port 0x2f8-0x2ff irq 5 > >>>: function 0 config 33 on pccard1 > >>>: sio4: type 16550A > >>>: sio4: unable to activate interrupt in fast mode - using normal mode > >>>: > >>>: And the obligatory 'detach' when I remove it. > >>> > >>>Cool. Sounds about right. Not sure you should be getting the > >>>allocation failed bit, but that's harmless, as is the fast interrupt > >>>message. > >>> > >>>: Any chance of this getting into RELENG_5_3? I'm not sure how that works > >>>: (since 5.3 gets "security and critical fixes" only), but I thought I > >>>: would ask. Does this classify as a critical fix? > >>> > >>>Hmmm. Lemme ask. > >>> > >>>Warner > >>> > >>> > >>> > >>> > >>Hi Warner, > >> > >>I was just wondering what the status of this is, if any. I'm about > >>commit our in-house installation procedures for 5.3, and others on my > >>team are going to want to migrate soon, but lack of PPP support on our > >>laptops isn't going to fly over too well, especially now that there is > >>some travelling going on. We want to stick to -release, as opposed to > >>-stable. > >> > >>I was thinking, I figure we have three possible options: > >> > >>1. If your patch is going to get merged into 5.3-release, that would be > >>the best route; but if that isn't going to happen, or not soon: > >> > >>2. Could we manually apply your patch to /usr/src after cvsup'ing before > >>buildword/buildkernel? > >> > >>3. Find a different PCMCIA modem that is supported by 5.3-release. Most > >>seem to be dirt-cheap these days, so if there is another one that works, > >>we wouldn't be opposed to picking these up. > >> > >>Your thoughts/advice? > >> > >>Cheers, > >>Duane > >> > >> > >> > >> > >>> > >>> > >>_______________________________________________ > >>freebsd-mobile@freebsd.org mailing list > >>http://lists.freebsd.org/mailman/listinfo/freebsd-mobile > >>To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org" > >> > >> > >> > > > >If its in RELENG_5 (-STABLE) you oughta be able to cvsup to that. Imo, > >with mobiles, for the time being they should be running -STABLE if > >they have support problems anyway. > > > > > Actually, I have considered that as a possibility. > > What are the most common negatives of running stable instead of release? > I have no experience tracking -STABLE, as we have always tracked > -RELEASE only. > > I think most of our obsession with running -RELEASE is more historical > than anything else, and the impression we've had since we started using > FreeBSD is that -RELEASE is more 'stable' then -STABLE. > > Also, I'm fairly certain that when we start upgrading servers, we > definately want to to go -RELEASE. The software developers on my team > generally try to maintain their laptops (they telecommute from far away, > so their laptops are more or less their 'lab' environments) as close to > as possible to my server configurations, so that there are no surprises > and we can generally apply the same knowledge between the two. > > Maybe I'm just being more anal-retentive than I need to be. :) > > Cheers, > Duane > > > > > > -STABLE is generally less stable than -RELEASE, but you won't see fixes, like these backported to -RELEASE, its for security stuff only from my understanding. -STABLE is slightly more administrative overhead, since you need to watch the lists, but personally, I've had great luck with it. On a few occassions, we've actually had to deploy -CURRENT in production, which worked out alright... but is a nightmare from an administrative perspective. Until 5.4 comes out, I suspect I'll be tracking -STABLE on all of my boxes, while they work out the last few things. --- Harrison Grundy