From owner-freebsd-mobile Tue Jan 19 19:18:12 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA19164 for freebsd-mobile-outgoing; Tue, 19 Jan 1999 19:18:12 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from azathoth.cyberwar.com (azathoth.cyberwar.com [206.88.128.48]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA19147; Tue, 19 Jan 1999 19:18:08 -0800 (PST) (envelope-from billg@cyberwar.com) Received: from wjgrun ([206.88.130.7]) by azathoth.cyberwar.com (8.8.8/8.8.8) with SMTP id WAA08048; Tue, 19 Jan 1999 22:17:43 -0500 (EST) (envelope-from billg@cyberwar.com) Message-Id: <4.1.19990119221230.0094b8c0@mail.cybernex.net> X-Sender: billg@pop.cyberwar.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 19 Jan 1999 22:20:28 -0500 To: freebsd-mobile@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG From: "Bill G." Subject: laptop install hangs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I am attempting to install FreeBSD on a new Umax Actionbook 318T Laptop, but it is hanging on the boot disk after it lists the kernel version / builder email address... The laptop has got an AMD K6-2 300MHz processor with 48MB RAM. I have tried using 2.2.8-RELEASE, 3.0-RELEASE, 2.2.8-19990119-SNAP, 3.0.0-19990106-SNAP, and 2.2.7-RELEASE-PAO boot disks. I am at a loss here ...and insight anyone could offer me would be greatly appreciated. The latest attempt hangs here: FreeBSD 3.0.0-19990106-SNAP #1: Thu Jan 7 15:52:05 GMT 1999 jkh@usw2.freebsd.org:/usr/src/sys/compile/BOOTMFS Thank you, Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message From owner-freebsd-mobile Tue Jan 19 20:26:03 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA27229 for freebsd-mobile-outgoing; Tue, 19 Jan 1999 20:26:03 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from top.worldcontrol.com (snblitz.sc.scruznet.com [165.227.132.84]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id UAA27224 for ; Tue, 19 Jan 1999 20:26:02 -0800 (PST) (envelope-from brian@worldcontrol.com) From: brian@worldcontrol.com Received: (qmail 90344 invoked by uid 100); 20 Jan 1999 04:25:54 -0000 Date: Tue, 19 Jan 1999 20:25:54 -0800 To: Nick Sayer Cc: freebsd-mobile@FreeBSD.ORG Subject: Re: Reclaiming irqs for unsupported PCI hardware? Message-ID: <19990119202553.A90328@top.worldcontrol.com> Mail-Followup-To: Nick Sayer , freebsd-mobile@freebsd.org References: <199901200105.RAA17165@quack.kfu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199901200105.RAA17165@quack.kfu.com>; from Nick Sayer on Tue, Jan 19, 1999 at 05:05:28PM -0800 Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Jan 19, 1999 at 05:05:28PM -0800, Nick Sayer wrote: > My laptop is basically out of IRQs. Windows seems to manage this > by bridging PCI devices together on a single IRQ. > > While I am writing, why is it necessary for the PCCARD controller > to use an IRQ? It only generates them at slot events, which happen, > what, every few _hours_ or so? Can't they be polled? IRQs are > precious in modern x86 machines (unfortunately). I cried similarly, and made a similar complaint about PCCARD services. The response was nada. What laptop do you have? I'm close to modifying the system myself to eliminate the IRQ for insertion. I have a further complication that when the PCCARD interrupt service routine tries to handle my modem card insertion the system freezes, however, if it is not done via the interrupt routine (card inserted before power on) it works fine. Other cards work correctly via insertion. The main thing that keeps me from doing so, is such changes will never be imported into FreeBSD unless the people with the power agree. I've got a pile of patches I have to apply after every sup in order to keep things working propertly on my hardware. 8-( -- Brian Litzinger To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message From owner-freebsd-mobile Wed Jan 20 11:53:22 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA10221 for freebsd-mobile-outgoing; Wed, 20 Jan 1999 11:53:22 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA10214 for ; Wed, 20 Jan 1999 11:53:19 -0800 (PST) (envelope-from tli@juniper.net) Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id LAA07482 for ; Wed, 20 Jan 1999 11:53:12 -0800 (PST) Received: (from tli@localhost) by chimp.juniper.net (8.8.8/8.7.3) id TAA28811; Wed, 20 Jan 1999 19:53:12 GMT To: freebsd-mobile@FreeBSD.ORG Subject: Re: APM power-off code References: <369C0195.2DE70CB3@acm.org> From: Tony Li Date: 20 Jan 1999 19:53:12 +0000 In-Reply-To: kientzle@acm.org's message of 13 Jan 99 02:14:45 GMT Message-ID: <82g1953emv.fsf@chimp.juniper.net> Lines: 18 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > These are some patches I've used with both 2.2.5 and 2.2.8. > They modify the shutdown code to actually turn off > power on a system shutdown. I personally use it > with my desktop machine; I find it quite convenient > to type "shutdown" and walk away knowing that the > machine will, in fact, turn itself off when it's > done cleaning up. I've got a possibly related question: On a Sony Vaio 505G running PAO, a reboot never actually gets you back to the BIOS. The system just seems to go into a spin loop and you have to manually do an emergency power off... Has anyone got a fix for this? Tony To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message From owner-freebsd-mobile Wed Jan 20 12:16:32 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA12371 for freebsd-mobile-outgoing; Wed, 20 Jan 1999 12:16:32 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from dingo.cdrom.com (castles232.castles.com [208.214.165.232]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA12365 for ; Wed, 20 Jan 1999 12:16:25 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id MAA00975; Wed, 20 Jan 1999 12:12:52 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901202012.MAA00975@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: brian@worldcontrol.com cc: Nick Sayer , freebsd-mobile@FreeBSD.ORG Subject: Re: Reclaiming irqs for unsupported PCI hardware? In-reply-to: Your message of "Tue, 19 Jan 1999 20:25:54 PST." <19990119202553.A90328@top.worldcontrol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Jan 1999 12:12:51 -0800 From: Mike Smith Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > While I am writing, why is it necessary for the PCCARD controller > > to use an IRQ? It only generates them at slot events, which happen, > > what, every few _hours_ or so? Can't they be polled? IRQs are > > precious in modern x86 machines (unfortunately). > > I cried similarly, and made a similar complaint about PCCARD > services. The response was nada. You said "why don't you lazy bastards fix this". We said "we are too bloody busy, fix it yourself". > I'm close to modifying the system myself to eliminate the IRQ > for insertion. > > I have a further complication that when the PCCARD interrupt service > routine tries to handle my modem card insertion the system freezes, > however, if it is not done via the interrupt routine (card inserted > before power on) it works fine. Other cards work correctly via > insertion. > > The main thing that keeps me from doing so, is such changes will never > be imported into FreeBSD unless the people with the power agree. Crap. Submit the patches, fix them when they break other peoples' hardware, and they'll get committed. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message From owner-freebsd-mobile Wed Jan 20 16:24:42 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA08676 for freebsd-mobile-outgoing; Wed, 20 Jan 1999 16:24:42 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from azathoth.cyberwar.com (azathoth.cyberwar.com [206.88.128.48]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA08671 for ; Wed, 20 Jan 1999 16:24:40 -0800 (PST) (envelope-from billg@cyberwar.com) Received: from wjgrun ([206.88.130.7]) by azathoth.cyberwar.com (8.8.8/8.8.8) with SMTP id TAA10382 for ; Wed, 20 Jan 1999 19:24:14 -0500 (EST) (envelope-from billg@cyberwar.com) Message-Id: <4.1.19990120192300.0094fbe0@mail.cybernex.net> X-Sender: billg@pop.cyberwar.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 20 Jan 1999 19:27:02 -0500 To: mobile@FreeBSD.ORG From: "Bill G." Subject: Re: laptop install hangs In-Reply-To: <60118.916803783@grey.cloud.rain.com> References: <4.1.19990119221230.0094b8c0@mail.cybernex.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 07:43 PM 1/19/99 -0800, you wrote: >"Bill G." writes: > I am attempting to install FreeBSD on a new Umax Actionbook 318T > Laptop, but it is hanging on the boot disk after it lists the kernel > version / builder email address... > >Do you get any more information if you boot with the "-v" flag? with -v, I get the following after kernel builder/dir: Calibrating clock(s) ... TSC clock: 300700886 Hz, i8254 clock: 1193261 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method anyone know when the 2.2.8-RELEASE-PAO boot disk will be ready? (I don't know if it will help, but I'd try anything at this point).. Thanks, Bill ....................................................................... Bill Grunfelder System Administrator wjgrun@cyberwar.com Cyber Warrior, Inc. http://www.cyberwar.com/ (201) 703-1517 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message From owner-freebsd-mobile Wed Jan 20 17:11:05 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA15519 for freebsd-mobile-outgoing; Wed, 20 Jan 1999 17:11:05 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from dingo.cdrom.com (castles232.castles.com [208.214.165.232]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA15507 for ; Wed, 20 Jan 1999 17:11:02 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id RAA04774; Wed, 20 Jan 1999 17:07:25 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901210107.RAA04774@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Bill G." cc: mobile@FreeBSD.ORG Subject: Re: laptop install hangs In-reply-to: Your message of "Wed, 20 Jan 1999 19:27:02 EST." <4.1.19990120192300.0094fbe0@mail.cybernex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Jan 1999 17:07:25 -0800 From: Mike Smith Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > At 07:43 PM 1/19/99 -0800, you wrote: > >"Bill G." writes: > > I am attempting to install FreeBSD on a new Umax Actionbook 318T > > Laptop, but it is hanging on the boot disk after it lists the kernel > > version / builder email address... > > > >Do you get any more information if you boot with the "-v" flag? > > with -v, I get the following after kernel builder/dir: > Calibrating clock(s) ... TSC clock: 300700886 Hz, i8254 clock: 1193261 Hz > CLK_USE_I8254_CALIBRATION not specified - using default frequency > Timecounter "i8254" frequency 1193182 Hz > CLK_USE_TSC_CALIBRATION not specified - using old calibration method > > anyone know when the 2.2.8-RELEASE-PAO boot disk will be ready? (I > don't know if it will help, but I'd try anything at this point).. I've seen this before, but only on a really broken old 486 motherboard. It had funky nonstandard realtime clock hardware, and the "time out eventually" loop took a very long time. If you can, leave the machine "stuck" there overnight. It may haul through, which will tell us something useful about your hardware. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message From owner-freebsd-mobile Thu Jan 21 02:05:20 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA14150 for freebsd-mobile-outgoing; Thu, 21 Jan 1999 02:05:20 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from top.worldcontrol.com (snblitz.sc.scruznet.com [165.227.132.84]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id CAA14144 for ; Thu, 21 Jan 1999 02:05:15 -0800 (PST) (envelope-from brian@worldcontrol.com) From: brian@worldcontrol.com Received: (qmail 91935 invoked by uid 100); 21 Jan 1999 10:05:05 -0000 Date: Thu, 21 Jan 1999 02:05:05 -0800 To: Mike Smith Cc: Nick Sayer , freebsd-mobile@FreeBSD.ORG Subject: Re: Reclaiming irqs for unsupported PCI hardware? Message-ID: <19990121020505.A91892@top.worldcontrol.com> Mail-Followup-To: Mike Smith , Nick Sayer , freebsd-mobile@FreeBSD.ORG References: <19990119202553.A90328@top.worldcontrol.com> <199901202012.MAA00975@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199901202012.MAA00975@dingo.cdrom.com>; from Mike Smith on Wed, Jan 20, 1999 at 12:12:51PM -0800 Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > [Brian Litzinger wrote:] > > I cried similarly, and made a similar complaint about PCCARD > > services. The response was nada. On Wed, Jan 20, 1999 at 12:12:51PM -0800, Mike Smith wrote: > You said "why don't you lazy bastards fix this". We said "we are too > bloody busy, fix it yourself". Here is the email that I sent on the subject. Can you find the quoted or paraphrased text within it: >From brian@top.worldcontrol.com Tue Nov 3 05:25:39 1998 >Date: Tue, 3 Nov 1998 05:25:39 -0800 >From: Brian Litzinger >To: freebsd-current@freebsd.org >Subject: PC Cards services without an IRQ? >Message-ID: <19981103052539.A3306@top.worldcontrol.com> >Mail-Followup-To: freebsd-current@freebsd.org >Mime-Version: 1.0 >Content-Type: text/plain; charset=us-ascii >X-Mailer: Mutt 0.94.9i >Status: RO >Content-Length: 612 >Lines: 18 > >I'm short IRQs on my laptop. Would it be feasible to have >the pccard services manager not rely on having one for itself? > >I'm suggesting that instead, when I change cards, I run a >program so the system will rescan the cardbus. > >Unless this is impossible, or already implemented in some way >I have not discovered, I'd like to take a stab at implementing >it. > >On the other hand, if there is "no f*cking way" it will every >be accepted into the source tree, let me know, and I'll look >for another solution. > >(I've given up on maintaining changes outside of the main tree) > >-- >Brian Litzinger You see that I'm being consistent with my experience of checking before hand to see if the "people in power" will accept a particular change. In my records, I did not receive any responses to the query. Hence my "nada" comment in the posting you are quoting. You'll also note the "no f*cking way" theoretical response I attribute to those "people in power". Why are the "people in power" so angry all the time? My take on the problem has been that Nate Williams and the PAO people don't get along. I suspect much progress could be made by rectifying that problem first. > > The main thing that keeps me from doing so, is such changes will never > > be imported into FreeBSD unless the people with the power agree. > > Crap. Submit the patches, fix them when they break other peoples' > hardware, and they'll get committed. I've found that unless the "people in power" like your idea you might as well not waste your time. Apparently, the PAO people have a solution for my particular problem. However, its hard to track -current and PAO at the same time. 8-( Have things changed? -- Brian Litzinger To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message From owner-freebsd-mobile Thu Jan 21 08:06:25 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA20294 for freebsd-mobile-outgoing; Thu, 21 Jan 1999 08:06:25 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from outland.cyberwar.com (outland.cyberwar.com [206.88.128.42]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA20289 for ; Thu, 21 Jan 1999 08:06:23 -0800 (PST) (envelope-from billg@cyberwar.com) Received: from zippy (zippy.cyberwar.com [206.88.128.80]) by outland.cyberwar.com (8.9.2/8.9.2) with SMTP id LAA01183; Thu, 21 Jan 1999 11:06:00 -0500 (EST) Message-Id: <4.1.19990121105842.00944450@pop.cyberwar.com> X-Sender: billg@pop.cyberwar.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 21 Jan 1999 11:03:53 -0500 To: Mike Smith From: Bill G Subject: Re: laptop install hangs Cc: mobile@FreeBSD.ORG In-Reply-To: <199901210107.RAA04774@dingo.cdrom.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I found out what FreeBSD didn't like about my laptop -- the Power Management. When I turned off APM in the BIOS, my problems disappeared, and I was up and running in no time! If anyone like like to know about my BIOS, or any tests I can do to help an individual or the FreeBSD project, please let me know. Sorry for the mess below - I tried to cut out the junk, but wanted to leave all the important comments for anyone in the future who might run into the same problem. Bill >> > I am attempting to install FreeBSD on a new Umax Actionbook 318T >> > Laptop, but it is hanging on the boot disk after it lists the kernel >> > version / builder email address... >> >Do you get any more information if you boot with the "-v" flag? >> with -v, I get the following after kernel builder/dir: >> Calibrating clock(s) ... TSC clock: 300700886 Hz, i8254 clock: 1193261 Hz >> CLK_USE_I8254_CALIBRATION not specified - using default frequency >> Timecounter "i8254" frequency 1193182 Hz >> CLK_USE_TSC_CALIBRATION not specified - using old calibration method >I've seen this before, but only on a really broken old 486 motherboard. >It had funky nonstandard realtime clock hardware, and the "time out >eventually" loop took a very long time. >If you can, leave the machine "stuck" there overnight. It may haul >through, which will tell us something useful about your hardware. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message From owner-freebsd-mobile Thu Jan 21 09:15:36 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA28415 for freebsd-mobile-outgoing; Thu, 21 Jan 1999 09:15:36 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from jli.com (jli.com [199.2.111.1]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id JAA28403 for ; Thu, 21 Jan 1999 09:15:33 -0800 (PST) (envelope-from trost@cloud.rain.com) Received: (qmail 19397 invoked by uid 4); 21 Jan 1999 17:15:24 -0000 Received: (qmail 74224 invoked from network); 21 Jan 1999 17:14:51 -0000 Received: from localhost.cloud.rain.com (HELO grey.cloud.rain.com) (127.0.0.1) by localhost.cloud.rain.com with SMTP; 21 Jan 1999 17:14:51 -0000 To: mobile@FreeBSD.ORG Subject: Re: Reclaiming irqs for unsupported PCI hardware? References: <19990121020505.A91892@top.worldcontrol.com> <19990119202553.A90328@top.worldcontrol.com> <199901202012.MAA00975@dingo.cdrom.com> In-reply-to: <19990121020505.A91892@top.worldcontrol.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <74220.916938889.1@grey.cloud.rain.com> Date: Thu, 21 Jan 1999 09:14:49 -0800 Message-ID: <74221.916938889@grey.cloud.rain.com> From: Bill Trost Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [Oops, sent this to Brian instead of -mobile like I had intended] brian@worldcontrol.com writes: You'll also note the "no f*cking way" theoretical response I attribute to those "people in power". Why are the "people in power" so angry all the time? ... > Crap. Submit the patches, fix them when they break other peoples' > hardware, and they'll get committed. OK, everyone, time to put our corks back in our spleens and stop spewing around the four-letter words. Brian, I am surprised your suggestion to switch to polling exclusively was ignored. Your idea to switch to polling is a good one. In fact, Nate Williams posted a message (see http://www.freebsd.org/cgi/mid.cgi?db=irt&id=199809241705.LAA05726@mt.sri.com) endorsing the idea. Try searching the freebsd-mobile archive for "option AND enable AND PCIC" and look at some of the messages there. In particular, one message (http://www.freebsd.org/cgi/mid.cgi?db=irt&id=199809241441.IAA04864@mt.sri.com) gives a good hint as to where you might want to start to implement a polled-only approach to managing card insertion and removal. Since the "Powers That Be" only want to commit tested code, I hereby volunteer as a (semi-CURRENT) guinea pig for your code. I even have a bit of experience debugging laptop kernel code... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message From owner-freebsd-mobile Thu Jan 21 11:31:58 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA16254 for freebsd-mobile-outgoing; Thu, 21 Jan 1999 11:31:58 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from dingo.cdrom.com (castles236.castles.com [208.214.165.236]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA16248 for ; Thu, 21 Jan 1999 11:31:56 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id LAA10433; Thu, 21 Jan 1999 11:28:19 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901211928.LAA10433@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Bill Trost cc: mobile@FreeBSD.ORG Subject: Re: Reclaiming irqs for unsupported PCI hardware? In-reply-to: Your message of "Thu, 21 Jan 1999 09:14:49 PST." <74221.916938889@grey.cloud.rain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Jan 1999 11:28:18 -0800 From: Mike Smith Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > [Oops, sent this to Brian instead of -mobile like I had intended] > > brian@worldcontrol.com writes: > You'll also note the "no f*cking way" theoretical response I > attribute to those "people in power". Why are the "people in power" > so angry all the time? > > ... > > > Crap. Submit the patches, fix them when they break other peoples' > > hardware, and they'll get committed. > > OK, everyone, time to put our corks back in our spleens and stop spewing > around the four-letter words. > > Brian, I am surprised your suggestion to switch to polling exclusively > was ignored. Your idea to switch to polling is a good one. In fact, > Nate Williams posted a message (see > http://www.freebsd.org/cgi/mid.cgi?db=irt&id=199809241705.LAA05726@mt.sri.com) > endorsing the idea. Here is a simple scenario which you are required to handle before polling can be considered a viable solution: A driver for a card is attached to the card. The driver has an interrupt handler. The card in question has an interrupt status register in which bits are set to indicate that the card requires service. The preemptive removal of the card is interpreted by the PCIC as an interrupt coming from the card. Once the card is gone, all of the registers in the mapped space read all-1s. Some solutions worth shooting down before they're suggested: - Polling for the card's presence every iteration of the interrupt handler loop. This is absurdly expensive. Don't suggest polling once on interrupt entry, unless you can guarantee the card won't be pulled during the interrupt handler's execution. - Polling off a clock interrupt - clock interrupts can be masked. - Hacking every interrupt handler to check for consequential evidence of the card being pulled. This is what the PAO folks do, but it's not acceptable simply because it makes assumptions about the card/ pcic that can't be justified, as well as being gross beyond belief. If you can surmount these technical issues without requiring asynchronous notification of card removal, then you'll have created something truly worthwhile. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message From owner-freebsd-mobile Thu Jan 21 15:14:02 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA10262 for freebsd-mobile-outgoing; Thu, 21 Jan 1999 15:03:37 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA10252 for ; Thu, 21 Jan 1999 15:03:35 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id QAA01770; Thu, 21 Jan 1999 16:03:15 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id QAA17586; Thu, 21 Jan 1999 16:03:14 -0700 Date: Thu, 21 Jan 1999 16:03:14 -0700 Message-Id: <199901212303.QAA17586@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: brian@worldcontrol.com Cc: Mike Smith , Nick Sayer , freebsd-mobile@FreeBSD.ORG Subject: Re: Reclaiming irqs for unsupported PCI hardware? In-Reply-To: <19990121020505.A91892@top.worldcontrol.com> References: <19990119202553.A90328@top.worldcontrol.com> <199901202012.MAA00975@dingo.cdrom.com> <19990121020505.A91892@top.worldcontrol.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > My take on the problem has been that Nate Williams and the PAO people > don't get along. For what i's worth, it's not an issue of 'get along' as much as an issue with 'development differencees'. The PAO folks are interested in laptop (and only laptop) support patches that work around bugs in the existin code and/or hardware, and I'm intersted in solutions that are relevant for both desktop *AND* laptop users. The PAO code oftens takes the 'easy' approach to the problem, which is great if the only consumer is a laptop user, but this won't work on a desktop, plus it often penalizes users who don't have problems. Next, I'm not the laptop guy anymore. Mike Smith *was* supposed to take it over, but WC keeps him too busy with other work, so currently there is no one doing the work. Warner Losh has been doing quite a bit of stuff, and Garrett Wollman is also working on some related issues, but for the most part the laptop stuff has been abandoned. (Even in PAO it's been back-burnered for the most part.) Does that mean that any/all patches are welcome? As long as I've got a say in the matter I'll speak my opinion on patches, but as far as getting my hands too dirty you can look elsewhere, as I simply don't have the time/desire to get involved anymore than I already am. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message From owner-freebsd-mobile Thu Jan 21 16:00:39 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA17828 for freebsd-mobile-outgoing; Thu, 21 Jan 1999 16:00:39 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA17817 for ; Thu, 21 Jan 1999 16:00:30 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.1/8.8.5) with ESMTP id AAA00804; Fri, 22 Jan 1999 00:51:49 +0100 (CET) To: Mike Smith cc: Bill Trost , mobile@FreeBSD.ORG Subject: Re: Reclaiming irqs for unsupported PCI hardware? In-reply-to: Your message of "Thu, 21 Jan 1999 11:28:18 PST." <199901211928.LAA10433@dingo.cdrom.com> Date: Fri, 22 Jan 1999 00:51:49 +0100 Message-ID: <802.916962709@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199901211928.LAA10433@dingo.cdrom.com>, Mike Smith writes: >Once the card is gone, all of the >registers in the mapped space read all-1s. This should not be relied on. It is my understanding that you will get fireworks bus-cycles on CardBus in this situation, and it will be left to the BIOS writer to figure out what should happen since I belive we end up in SMM mode in that case... Also I have not seen any documentation saying the all-1s is a standard, but would accept a survey of pcic's which show this to be universal so far. > - Polling for the card's presence every iteration of the interrupt > handler loop. This is absurdly expensive. Don't suggest polling > once on interrupt entry, unless you can guarantee the card won't be > pulled during the interrupt handler's execution. There is no way to guarantee that the card will not be pulled in the next N microseconds. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message From owner-freebsd-mobile Thu Jan 21 21:28:17 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA18778 for freebsd-mobile-outgoing; Thu, 21 Jan 1999 21:28:17 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id VAA18741 for ; Thu, 21 Jan 1999 21:28:13 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 103YYN-0003KQ-00; Thu, 21 Jan 1999 21:50:43 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id VAA83598; Thu, 21 Jan 1999 21:48:34 -0700 (MST) Message-Id: <199901220448.VAA83598@harmony.village.org> To: Nate Williams Subject: Re: Reclaiming irqs for unsupported PCI hardware? Cc: freebsd-mobile@FreeBSD.ORG In-reply-to: Your message of "Thu, 21 Jan 1999 16:03:14 MST." <199901212303.QAA17586@mt.sri.com> References: <199901212303.QAA17586@mt.sri.com> <19990119202553.A90328@top.worldcontrol.com> <199901202012.MAA00975@dingo.cdrom.com> <19990121020505.A91892@top.worldcontrol.com> Date: Thu, 21 Jan 1999 21:48:34 -0700 From: Warner Losh Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199901212303.QAA17586@mt.sri.com> Nate Williams writes: : Warner Losh has been doing quite a bit of : stuff, and Garrett Wollman is also working on some related issues, but : for the most part the laptop stuff has been abandoned. There are a number of nagging issues for running on my libretto that haven't made it to the level of major annoyances yet. I work on it when I can, but haven't had the time to devote to it like I want... However, I know at least one core member who just got a cardbus laptop and keeps threatening to do a cardbus implementation so that he can get a supported scsi card. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message From owner-freebsd-mobile Thu Jan 21 21:42:39 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA21372 for freebsd-mobile-outgoing; Thu, 21 Jan 1999 21:42:39 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from dingo.cdrom.com (castles327.castles.com [208.214.167.27]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA21352 for ; Thu, 21 Jan 1999 21:42:36 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id RAA12743; Thu, 21 Jan 1999 17:58:34 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901220158.RAA12743@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Poul-Henning Kamp cc: Mike Smith , Bill Trost , mobile@FreeBSD.ORG Subject: Re: Reclaiming irqs for unsupported PCI hardware? In-reply-to: Your message of "Fri, 22 Jan 1999 00:51:49 +0100." <802.916962709@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Jan 1999 17:58:34 -0800 From: Mike Smith Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > In message <199901211928.LAA10433@dingo.cdrom.com>, Mike Smith writes: > > >Once the card is gone, all of the > >registers in the mapped space read all-1s. > > This should not be relied on. It is my understanding that you will > get fireworks bus-cycles on CardBus in this situation, and it will > be left to the BIOS writer to figure out what should happen since > I belive we end up in SMM mode in that case... Cardbus is completely different. I can hardly wait to see what happens when you pull a cardbus card. > Also I have not seen any documentation saying the all-1s is a standard, > but would accept a survey of pcic's which show this to be universal > so far. The input drivers are pulled up, IIRC, so in the absence of anything driving them, and modulo noise from the card departing, I'd expect an *eventaul* all-1s. I certainly wouldn't want to rely on it though. > > - Polling for the card's presence every iteration of the interrupt > > handler loop. This is absurdly expensive. Don't suggest polling > > once on interrupt entry, unless you can guarantee the card won't be > > pulled during the interrupt handler's execution. > > There is no way to guarantee that the card will not be pulled in the > next N microseconds. Rrrg. This is actually a really good point, and I can see where this leads to. 1) DO NOT REMOVE THE CARD UNTIL YOU HAVE SHUT IT DOWN. 2) Poll for insertions/removals since the cards are never active in either state (see point 1). Perhaps we're just looking at this the wrong way? We don't try to detect when floppies are stupidly removed, perhaps we shouldn't try to do it with pccard/cardbus cards either? Commentary? Are we trying too hard to do something that's not worth the effort? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message From owner-freebsd-mobile Fri Jan 22 00:01:41 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA05886 for freebsd-mobile-outgoing; Fri, 22 Jan 1999 00:01:41 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from mail.rdc1.nj.home.com (ha1.rdc1.nj.home.com [24.3.128.66]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA05881 for ; Fri, 22 Jan 1999 00:01:40 -0800 (PST) (envelope-from garycor@home.com) Received: from home.com ([24.3.185.85]) by mail.rdc1.nj.home.com (InterMail v4.00.03 201-229-104) with ESMTP id <19990122080130.CKHC11472.mail.rdc1.nj.home.com@home.com> for ; Fri, 22 Jan 1999 00:01:30 -0800 Message-ID: <36A80B3F.80FA5E87@home.com> Date: Fri, 22 Jan 1999 00:23:11 -0500 From: "Gary T. Corcoran" X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: mobile@FreeBSD.ORG Subject: Re: Reclaiming irqs for unsupported PCI hardware? References: <199901220158.RAA12743@dingo.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mike Smith wrote: > > There is no way to guarantee that the card will not be pulled in the > > next N microseconds. > > Rrrg. This is actually a really good point, Indeed. > and I can see where this leads to. > > 1) DO NOT REMOVE THE CARD UNTIL YOU HAVE SHUT IT DOWN. Windows 9x also REQUIRES this. > 2) Poll for insertions/removals since the cards are never active in > either state (see point 1). Good idea - sounds like we could free up an IRQ if I'm understanding the situation correctly (an IRQ is used for little more than notification of card insertion ?). I take it that the IRQ assigned to the card itself is a separate one - is that correct? > Perhaps we're just looking at this the wrong way? We don't try to > detect when floppies are stupidly removed, perhaps we shouldn't try to > do it with pccard/cardbus cards either? > > Commentary? Are we trying too hard to do something that's not worth > the effort? After following this thread, I've come to the conclusion that since the PCIC hardware _is not designed_ to allow arbitrary card removal (e.g. it doesn't auto-shutoff the IRQ line), we're trying to come up with, at best, a workaround, for something that the user _just shouldn't do_. In other words, just make sure mobile users know they _must_ shutdown a card before removing it, and forget about trying to handle stupid (or accidental) user actions. Besides, I'd rather see work going towards enabling either multi-function cards or Cardbus cards... ;-) If only there were more hours in a day... Gary To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message From owner-freebsd-mobile Fri Jan 22 01:11:38 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA13237 for freebsd-mobile-outgoing; Fri, 22 Jan 1999 01:11:38 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA13228 for ; Fri, 22 Jan 1999 01:11:35 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.1/8.8.5) with ESMTP id KAA02127; Fri, 22 Jan 1999 10:09:49 +0100 (CET) To: Mike Smith cc: Bill Trost , mobile@FreeBSD.ORG Subject: Re: Reclaiming irqs for unsupported PCI hardware? In-reply-to: Your message of "Thu, 21 Jan 1999 17:58:34 PST." <199901220158.RAA12743@dingo.cdrom.com> Date: Fri, 22 Jan 1999 10:09:47 +0100 Message-ID: <2125.916996187@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199901220158.RAA12743@dingo.cdrom.com>, Mike Smith writes: >> In message <199901211928.LAA10433@dingo.cdrom.com>, Mike Smith writes: >> >> >Once the card is gone, all of the >> >registers in the mapped space read all-1s. >> >> This should not be relied on. It is my understanding that you will >> get fireworks bus-cycles on CardBus in this situation, and it will >> be left to the BIOS writer to figure out what should happen since >> I belive we end up in SMM mode in that case... > >Cardbus is completely different. I can hardly wait to see what happens >when you pull a cardbus card. You get special bus cycles I belive, and aborted IO if you try, this should be catchable and if drivers are aware of it, recoverable. >> Also I have not seen any documentation saying the all-1s is a standard, >> but would accept a survey of pcic's which show this to be universal >> so far. > >The input drivers are pulled up, IIRC, so in the absence of anything >driving them, and modulo noise from the card departing, I'd expect an >*eventaul* all-1s. I certainly wouldn't want to rely on it though. Well, the point is, if you could rely on it, you could do something... >> There is no way to guarantee that the card will not be pulled in the >> next N microseconds. > >Rrrg. This is actually a really good point, and I can see where this >leads to. > > 1) DO NOT REMOVE THE CARD UNTIL YOU HAVE SHUT IT DOWN. > 2) Poll for insertions/removals since the cards are never active in > either state (see point 1). > >Perhaps we're just looking at this the wrong way? We don't try to >detect when floppies are stupidly removed, perhaps we shouldn't try to >do it with pccard/cardbus cards either? > >Commentary? Are we trying too hard to do something that's not worth >the effort? PCMCIA/PCcard is fundamentally flawed in this respect, we can add some kludges (see "gone" in sio.c" for instance), but we can never guarantee that it will not crash the machine. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message From owner-freebsd-mobile Fri Jan 22 07:03:19 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA25855 for freebsd-mobile-outgoing; Fri, 22 Jan 1999 07:03:19 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from hotpoint.dcs.qmw.ac.uk (hotpoint.dcs.qmw.ac.uk [138.37.88.162]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA25846 for ; Fri, 22 Jan 1999 07:03:13 -0800 (PST) (envelope-from scott@dcs.qmw.ac.uk) Received: from brunos-sun.dcs.qmw.ac.uk [138.37.88.185]; by hotpoint.dcs.qmw.ac.uk (8.8.7/8.8.5/S-4.0) with SMTP; id PAA21479; Fri, 22 Jan 1999 15:02:50 GMT Received: locally by brunos-sun (SMI-8.6/QMW-client-3.2b); poster "scott"; id PAA25434; Fri, 22 Jan 1999 15:00:29 GMT Message-ID: <19990122150028.G22912@dcs.qmw.ac.uk> Date: Fri, 22 Jan 1999 15:00:28 +0000 From: Scott Mitchell To: Mike Smith , Poul-Henning Kamp Cc: Bill Trost , mobile@FreeBSD.ORG Subject: Re: Reclaiming irqs for unsupported PCI hardware? References: <802.916962709@critter.freebsd.dk> <199901220158.RAA12743@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199901220158.RAA12743@dingo.cdrom.com>; from Mike Smith on Thu, Jan 21, 1999 at 05:58:34PM -0800 Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jan 21, 1999 at 05:58:34PM -0800, Mike Smith wrote: > > In message <199901211928.LAA10433@dingo.cdrom.com>, Mike Smith writes: > > > > >Once the card is gone, all of the > > >registers in the mapped space read all-1s. > > > > This should not be relied on. It is my understanding that you will > > get fireworks bus-cycles on CardBus in this situation, and it will > > be left to the BIOS writer to figure out what should happen since > > I belive we end up in SMM mode in that case... > > Cardbus is completely different. I can hardly wait to see what happens > when you pull a cardbus card. > > > Also I have not seen any documentation saying the all-1s is a standard, > > but would accept a survey of pcic's which show this to be universal > > so far. > > The input drivers are pulled up, IIRC, so in the absence of anything > driving them, and modulo noise from the card departing, I'd expect an > *eventaul* all-1s. I certainly wouldn't want to rely on it though. > > > > - Polling for the card's presence every iteration of the interrupt > > > handler loop. This is absurdly expensive. Don't suggest polling > > > once on interrupt entry, unless you can guarantee the card won't be > > > pulled during the interrupt handler's execution. > > > > There is no way to guarantee that the card will not be pulled in the > > next N microseconds. > > Rrrg. This is actually a really good point, and I can see where this > leads to. > > 1) DO NOT REMOVE THE CARD UNTIL YOU HAVE SHUT IT DOWN. > 2) Poll for insertions/removals since the cards are never active in > either state (see point 1). > > Perhaps we're just looking at this the wrong way? We don't try to > detect when floppies are stupidly removed, perhaps we shouldn't try to > do it with pccard/cardbus cards either? > > Commentary? Are we trying too hard to do something that's not worth > the effort? Probably. There's no way to gracefully deal with a card getting yanked while you're servicing an interrupt from it, and no technical means to prevent such a thing from happening, so anything beyond the current 'gone' flag kludge is likely to be wasted effort. Of course even that minimal check is gone if you only check for card removals on inactive cards. Speaking of which, how *do* you shut down a card/slot from userland other than by using zzz? The last version of PAO I played with had a 'power' option to pccardc (and presumably an associated ioctl) that did this, but I can't find anything like that in 3.0. If no-one else is already tackling it, I might start looking at this and the other annoying interactions between my ThinkPad and the pccard/apm drivers once I get my Xircom driver finished. Cheers, Scott -- =========================================================================== Scott Mitchell | PGP Key ID |"If I can't have my coffee, I'm just | 0x54B171B9 | like a dried up piece of roast goat" QMW College, London, UK | 0xAA775B8B | -- J. S. Bach. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message From owner-freebsd-mobile Fri Jan 22 09:03:31 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA08588 for freebsd-mobile-outgoing; Fri, 22 Jan 1999 09:03:31 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from send104.yahoomail.com (send104.yahoomail.com [205.180.60.122]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id JAA08582 for ; Fri, 22 Jan 1999 09:03:29 -0800 (PST) (envelope-from dfrascone@yahoo.com) Message-ID: <19990122170609.1694.rocketmail@send104.yahoomail.com> Received: from [192.9.25.22] by send104.yahoomail.com; Fri, 22 Jan 1999 09:06:09 PST Date: Fri, 22 Jan 1999 09:06:09 -0800 (PST) From: Dave Frascone Reply-To: chaos@mindspring.com Subject: Where do I submit changes to the PCMCIA stuff To: mobile@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I ported my LinkSys combo modem. (Well, I pointed the pccard.conf file in the right direction). The ethernet portion of the card now works. Where do I send the patches? Later, Dave == ---- Dave Frascone chaos@mindspring.com _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message From owner-freebsd-mobile Fri Jan 22 09:40:02 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA12265 for freebsd-mobile-outgoing; Fri, 22 Jan 1999 09:40:02 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA12172 for ; Fri, 22 Jan 1999 09:39:58 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id KAA10172; Fri, 22 Jan 1999 10:39:47 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id KAA21533; Fri, 22 Jan 1999 10:39:42 -0700 Date: Fri, 22 Jan 1999 10:39:42 -0700 Message-Id: <199901221739.KAA21533@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Gary T. Corcoran" Cc: mobile@FreeBSD.ORG Subject: Re: Reclaiming irqs for unsupported PCI hardware? In-Reply-To: <36A80B3F.80FA5E87@home.com> References: <199901220158.RAA12743@dingo.cdrom.com> <36A80B3F.80FA5E87@home.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Perhaps we're just looking at this the wrong way? We don't try to > > detect when floppies are stupidly removed, perhaps we shouldn't try to > > do it with pccard/cardbus cards either? > > > > Commentary? Are we trying too hard to do something that's not worth > > the effort? > > After following this thread, I've come to the conclusion that since > the PCIC hardware _is not designed_ to allow arbitrary card removal > (e.g. it doesn't auto-shutoff the IRQ line) Sure it does. IRQ's are no longer generated on that piece of hardware, but it's possible that the IRQ routine was in the middle of processing the previous (valid) IRQ that was generated 'just prior' to the removal. > we're trying to come up > with, at best, a workaround, for something that the user _just shouldn't > do_. What users shouldn't do and what they actually do are too different things. 'But it works in Linux/Win95' is the response you'll get when you explain to them why they shouldn't yank their 'active' cards. (Although, as I understand it, Win98 no longer allows this and locks up the computer, unlike Win95. *Most* cards can be yanked under '95, but some can't.) > In other words, just make sure mobile users know they _must_ > shutdown a card before removing it, and forget about trying to handle > stupid (or accidental) user actions. The use of the IRQ makes it less painful *IF* the user yanks their card. Is it worth making it easier? I don't know. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message From owner-freebsd-mobile Fri Jan 22 09:40:05 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA12324 for freebsd-mobile-outgoing; Fri, 22 Jan 1999 09:40:05 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA12264 for ; Fri, 22 Jan 1999 09:40:02 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id KAA10130; Fri, 22 Jan 1999 10:34:41 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id KAA21516; Fri, 22 Jan 1999 10:34:40 -0700 Date: Fri, 22 Jan 1999 10:34:40 -0700 Message-Id: <199901221734.KAA21516@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Mike Smith Cc: Poul-Henning Kamp , Bill Trost , mobile@FreeBSD.ORG Subject: Re: Reclaiming irqs for unsupported PCI hardware? In-Reply-To: <199901220158.RAA12743@dingo.cdrom.com> References: <802.916962709@critter.freebsd.dk> <199901220158.RAA12743@dingo.cdrom.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > - Polling for the card's presence every iteration of the interrupt > > > handler loop. This is absurdly expensive. Don't suggest polling > > > once on interrupt entry, unless you can guarantee the card won't be > > > pulled during the interrupt handler's execution. > > > > There is no way to guarantee that the card will not be pulled in the > > next N microseconds. > > Rrrg. This is actually a really good point, and I can see where this > leads to. > We have no 'shutdown' procedure, unfortunately. Note, *most* cards that you pull are probably not 'active', and drivers can be coded to check for inactivity/removal. It's not pretty, but it's the best solution that I'm aware of. However, it requires that we use an interrupt routine for removal, else there's no way to 'interrupt' the interrupt handler and modify the drivers' flag to let it know there is no hardware. > 1) DO NOT REMOVE THE CARD UNTIL YOU HAVE SHUT IT DOWN. > 2) Poll for insertions/removals since the cards are never active in > either state (see point 1). > > Perhaps we're just looking at this the wrong way? We don't try to > detect when floppies are stupidly removed, perhaps we shouldn't try to > do it with pccard/cardbus cards either? We have to, because all other OS's do. And, it's really easy and uses up very little CPU to do. > Commentary? Are we trying too hard to do something that's not worth > the effort? It's impossible to crrrectly handle hot-swapping of PCMCIA cards, but you can get it mostly right. Trying to get it more right makes things really compilicated, and is probably not worth the effort. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message From owner-freebsd-mobile Fri Jan 22 11:36:02 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA29275 for freebsd-mobile-outgoing; Fri, 22 Jan 1999 11:36:02 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA29225 for ; Fri, 22 Jan 1999 11:36:00 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id LAA00927; Fri, 22 Jan 1999 11:30:31 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901221930.LAA00927@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Nate Williams cc: "Gary T. Corcoran" , mobile@FreeBSD.ORG Subject: Re: Reclaiming irqs for unsupported PCI hardware? In-reply-to: Your message of "Fri, 22 Jan 1999 10:39:42 MST." <199901221739.KAA21533@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 22 Jan 1999 11:30:31 -0800 From: Mike Smith Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > Perhaps we're just looking at this the wrong way? We don't try to > > > detect when floppies are stupidly removed, perhaps we shouldn't try to > > > do it with pccard/cardbus cards either? > > > > > > Commentary? Are we trying too hard to do something that's not worth > > > the effort? > > > > After following this thread, I've come to the conclusion that since > > the PCIC hardware _is not designed_ to allow arbitrary card removal > > (e.g. it doesn't auto-shutoff the IRQ line) > > Sure it does. IRQ's are no longer generated on that piece of hardware, > but it's possible that the IRQ routine was in the middle of processing > the previous (valid) IRQ that was generated 'just prior' to the removal. Uh, it's also possible for the removal itself to generate an interrupt - I had this 100% repeatable on the Sharp I used to use. > > we're trying to come up > > with, at best, a workaround, for something that the user _just shouldn't > > do_. > > What users shouldn't do and what they actually do are too different > things. 'But it works in Linux/Win95' is the response you'll get when > you explain to them why they shouldn't yank their 'active' cards. > > (Although, as I understand it, Win98 no longer allows this and locks up > the computer, unlike Win95. *Most* cards can be yanked under '95, but > some can't.) The observation so far has been that Windows will lock up if you yank a card on a machine that uses polling. I'm thinking now that we'd be better off taking the hard line - the card must be shut off in software before removing. > > In other words, just make sure mobile users know they _must_ > > shutdown a card before removing it, and forget about trying to handle > > stupid (or accidental) user actions. > > The use of the IRQ makes it less painful *IF* the user yanks their > card. Is it worth making it easier? I don't know. That's it in a nutshell. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message From owner-freebsd-mobile Fri Jan 22 11:42:44 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA00217 for freebsd-mobile-outgoing; Fri, 22 Jan 1999 11:42:44 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA00212 for ; Fri, 22 Jan 1999 11:42:41 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id MAA11270; Fri, 22 Jan 1999 12:40:05 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id MAA22323; Fri, 22 Jan 1999 12:40:04 -0700 Date: Fri, 22 Jan 1999 12:40:04 -0700 Message-Id: <199901221940.MAA22323@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Mike Smith Cc: Nate Williams , "Gary T. Corcoran" , mobile@FreeBSD.ORG Subject: Re: Reclaiming irqs for unsupported PCI hardware? In-Reply-To: <199901221930.LAA00927@dingo.cdrom.com> References: <199901221739.KAA21533@mt.sri.com> <199901221930.LAA00927@dingo.cdrom.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > > Perhaps we're just looking at this the wrong way? We don't try to > > > > detect when floppies are stupidly removed, perhaps we shouldn't try to > > > > do it with pccard/cardbus cards either? > > > > > > > > Commentary? Are we trying too hard to do something that's not worth > > > > the effort? > > > > > > After following this thread, I've come to the conclusion that since > > > the PCIC hardware _is not designed_ to allow arbitrary card removal > > > (e.g. it doesn't auto-shutoff the IRQ line) > > > > Sure it does. IRQ's are no longer generated on that piece of hardware, > > but it's possible that the IRQ routine was in the middle of processing > > the previous (valid) IRQ that was generated 'just prior' to the removal. > > Uh, it's also possible for the removal itself to generate an interrupt > - I had this 100% repeatable on the Sharp I used to use. Right, but this does not work reliably on all PCIC controllers. It works on mine, but I know a number of controllers it does not work on (for whatever reason). > > > we're trying to come up > > > with, at best, a workaround, for something that the user _just shouldn't > > > do_. > > > > What users shouldn't do and what they actually do are too different > > things. 'But it works in Linux/Win95' is the response you'll get when > > you explain to them why they shouldn't yank their 'active' cards. > > > > (Although, as I understand it, Win98 no longer allows this and locks up > > the computer, unlike Win95. *Most* cards can be yanked under '95, but > > some can't.) > > The observation so far has been that Windows will lock up if you yank a > card on a machine that uses polling. I'm thinking now that we'd be > better off taking the hard line - the card must be shut off in software > before removing. Depends. Maybe Win98 now defaults to polling mode hen, since in Win95 with the same hardware it works, and it doesn't in Win98. (So I've heard, I've not had any direct experience with this). > > > In other words, just make sure mobile users know they _must_ > > > shutdown a card before removing it, and forget about trying to handle > > > stupid (or accidental) user actions. > > > > The use of the IRQ makes it less painful *IF* the user yanks their > > card. Is it worth making it easier? I don't know. > > That's it in a nutshell. You got it. If we've got the IRQ, we *can* make it safer. But, it doesn't work reliably on some hardware, and it 'wastes' an interrupt that might otherwise be used for something else. (I'm using the term 'waste' loosely here, since I think it makes the system more robust..) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message From owner-freebsd-mobile Fri Jan 22 11:46:45 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA00650 for freebsd-mobile-outgoing; Fri, 22 Jan 1999 11:46:45 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA00643 for ; Fri, 22 Jan 1999 11:46:43 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id LAA00993; Fri, 22 Jan 1999 11:41:58 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901221941.LAA00993@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Nate Williams cc: Mike Smith , "Gary T. Corcoran" , mobile@FreeBSD.ORG Subject: Re: Reclaiming irqs for unsupported PCI hardware? In-reply-to: Your message of "Fri, 22 Jan 1999 12:40:04 MST." <199901221940.MAA22323@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 22 Jan 1999 11:41:58 -0800 From: Mike Smith Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > > > > Sure it does. IRQ's are no longer generated on that piece of hardware, > > > but it's possible that the IRQ routine was in the middle of processing > > > the previous (valid) IRQ that was generated 'just prior' to the removal. > > > > Uh, it's also possible for the removal itself to generate an interrupt > > - I had this 100% repeatable on the Sharp I used to use. > > Right, but this does not work reliably on all PCIC controllers. It > works on mine, but I know a number of controllers it does not work on > (for whatever reason). Sorry, you're missing my point - the removal causes a *card* interrupt, not a PCIC interrupt. > > > > In other words, just make sure mobile users know they _must_ > > > > shutdown a card before removing it, and forget about trying to handle > > > > stupid (or accidental) user actions. > > > > > > The use of the IRQ makes it less painful *IF* the user yanks their > > > card. Is it worth making it easier? I don't know. > > > > That's it in a nutshell. > > You got it. If we've got the IRQ, we *can* make it safer. But, it > doesn't work reliably on some hardware, and it 'wastes' an interrupt > that might otherwise be used for something else. (I'm using the term > 'waste' loosely here, since I think it makes the system more robust..) Understood. Hmm. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message From owner-freebsd-mobile Fri Jan 22 11:50:41 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA01192 for freebsd-mobile-outgoing; Fri, 22 Jan 1999 11:50:41 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA01185 for ; Fri, 22 Jan 1999 11:50:38 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id MAA11361; Fri, 22 Jan 1999 12:50:16 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id MAA22394; Fri, 22 Jan 1999 12:50:15 -0700 Date: Fri, 22 Jan 1999 12:50:15 -0700 Message-Id: <199901221950.MAA22394@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Mike Smith Cc: Nate Williams , "Gary T. Corcoran" , mobile@FreeBSD.ORG Subject: Re: Reclaiming irqs for unsupported PCI hardware? In-Reply-To: <199901221941.LAA00993@dingo.cdrom.com> References: <199901221940.MAA22323@mt.sri.com> <199901221941.LAA00993@dingo.cdrom.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > > Sure it does. IRQ's are no longer generated on that piece of hardware, > > > > but it's possible that the IRQ routine was in the middle of processing > > > > the previous (valid) IRQ that was generated 'just prior' to the removal. > > > > > > Uh, it's also possible for the removal itself to generate an interrupt > > > - I had this 100% repeatable on the Sharp I used to use. > > > > Right, but this does not work reliably on all PCIC controllers. It > > works on mine, but I know a number of controllers it does not work on > > (for whatever reason). > > Sorry, you're missing my point - the removal causes a *card* interrupt, > not a PCIC interrupt. Ah, gotcha. FWIW, supposedly the PCIC interrupt supercedes the card interrupt in the current code. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message From owner-freebsd-mobile Fri Jan 22 13:23:29 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA15457 for freebsd-mobile-outgoing; Fri, 22 Jan 1999 13:23:29 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA15444 for ; Fri, 22 Jan 1999 13:23:24 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.1/8.8.5) with ESMTP id WAA05074; Fri, 22 Jan 1999 22:21:24 +0100 (CET) To: Nate Williams cc: Mike Smith , "Gary T. Corcoran" , mobile@FreeBSD.ORG Subject: Re: Reclaiming irqs for unsupported PCI hardware? In-reply-to: Your message of "Fri, 22 Jan 1999 12:50:15 MST." <199901221950.MAA22394@mt.sri.com> Date: Fri, 22 Jan 1999 22:21:23 +0100 Message-ID: <5072.917040083@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199901221950.MAA22394@mt.sri.com>, Nate Williams writes: >> > > > Sure it does. IRQ's are no longer generated on that piece of hardware, >> > > > but it's possible that the IRQ routine was in the middle of processing >> > > > the previous (valid) IRQ that was generated 'just prior' to the removal. >> > > >> > > Uh, it's also possible for the removal itself to generate an interrupt >> > > - I had this 100% repeatable on the Sharp I used to use. >> > >> > Right, but this does not work reliably on all PCIC controllers. It >> > works on mine, but I know a number of controllers it does not work on >> > (for whatever reason). >> >> Sorry, you're missing my point - the removal causes a *card* interrupt, >> not a PCIC interrupt. > >Ah, gotcha. FWIW, supposedly the PCIC interrupt supercedes the card >interrupt in the current code. :) Yes, but that doesn't help you if the current context is a section of code with interrupts masked/disabled... Anyway, I belive that the "->gone" hack in sio.c is probably as far as it pays to go down this path anyway. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message From owner-freebsd-mobile Fri Jan 22 15:16:42 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA00213 for freebsd-mobile-outgoing; Fri, 22 Jan 1999 15:16:42 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA00198 for ; Fri, 22 Jan 1999 15:16:40 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id QAA13120; Fri, 22 Jan 1999 16:16:16 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id QAA23362; Fri, 22 Jan 1999 16:16:15 -0700 Date: Fri, 22 Jan 1999 16:16:15 -0700 Message-Id: <199901222316.QAA23362@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Poul-Henning Kamp Cc: Nate Williams , Mike Smith , "Gary T. Corcoran" , mobile@FreeBSD.ORG Subject: Re: Reclaiming irqs for unsupported PCI hardware? In-Reply-To: <5072.917040083@critter.freebsd.dk> References: <199901221950.MAA22394@mt.sri.com> <5072.917040083@critter.freebsd.dk> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >> > > > Sure it does. IRQ's are no longer generated on that piece of hardware, > >> > > > but it's possible that the IRQ routine was in the middle of processing > >> > > > the previous (valid) IRQ that was generated 'just prior' to the removal. > >> > > > >> > > Uh, it's also possible for the removal itself to generate an interrupt > >> > > - I had this 100% repeatable on the Sharp I used to use. > >> > > >> > Right, but this does not work reliably on all PCIC controllers. It > >> > works on mine, but I know a number of controllers it does not work on > >> > (for whatever reason). > >> > >> Sorry, you're missing my point - the removal causes a *card* interrupt, > >> not a PCIC interrupt. > > > >Ah, gotcha. FWIW, supposedly the PCIC interrupt supercedes the card > >interrupt in the current code. :) > > Yes, but that doesn't help you if the current context is a section of code > with interrupts masked/disabled... Exactly. This is why the current PCCARD code can still lockup if your in the middle of doing a SLIP/PPP download and you yank the card out. :( > Anyway, I belive that the "->gone" hack in sio.c is probably as > far as it pays to go down this path anyway. Totally agreed. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message From owner-freebsd-mobile Fri Jan 22 15:44:17 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA02968 for freebsd-mobile-outgoing; Fri, 22 Jan 1999 15:44:17 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA02962 for ; Fri, 22 Jan 1999 15:44:14 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id QAA13365; Fri, 22 Jan 1999 16:44:01 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id QAA23619; Fri, 22 Jan 1999 16:44:01 -0700 Date: Fri, 22 Jan 1999 16:44:01 -0700 Message-Id: <199901222344.QAA23619@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: chaos@mindspring.com Cc: mobile@FreeBSD.ORG Subject: Re: Where do I submit changes to the PCMCIA stuff In-Reply-To: <19990122170609.1694.rocketmail@send104.yahoomail.com> References: <19990122170609.1694.rocketmail@send104.yahoomail.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I ported my LinkSys combo modem. (Well, I pointed the pccard.conf > file in the right direction). The ethernet portion of the card now > works. > > Where do I send the patches? Right to this mailing list. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message From owner-freebsd-mobile Fri Jan 22 15:47:59 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA03671 for freebsd-mobile-outgoing; Fri, 22 Jan 1999 15:47:59 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from gongshow.masterplan.org (masterplan.powersurfr.com [24.108.38.69]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA03662 for ; Fri, 22 Jan 1999 15:47:57 -0800 (PST) (envelope-from jbg@masterplan.org) Received: from localhost (jbg@localhost) by gongshow.masterplan.org (8.8.8/8.8.8) with SMTP id QAA11250 for ; Fri, 22 Jan 1999 16:47:38 -0700 (MST) (envelope-from jbg@masterplan.org) Date: Fri, 22 Jan 1999 16:47:36 -0700 (MST) From: Jason George X-Sender: jbg@gongshow To: freebsd-mobile@FreeBSD.ORG Subject: Xircom PCMCIA driver Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I was checking around to see if Xircom or Intel PCMCIA network adapters were supported under FreeBSD, and was disappointed to see that they weren't. I did some research on Linux's support of these cards, and I found a driver: /* [xirc2ps_cs.c wk 14.04.97] (1.31 1998/12/09 19:32:55) * Xircom Creditcard Ethernet Adapter IIps driver * * This driver works for the CE2, CEM28, CEM33, CE3 and CEM56 cards. * The CEM56 has some problems, but it works. * The CEII card with the 14k4 modem and other old cards do not work. * * Written by Werner Koch (werner.koch@guug.de), * based on David Hinds skeleton driver. * * You can get the latest driver revision from * "http://www.d.shuttle.de/isil/xircom/xirc2ps.html" * Now, the driver is GPL'ed, but... [cut and paste] * * ALTERNATIVELY, this driver may be distributed under the terms of * the following license, in which case the provisions of this license * are required INSTEAD OF the GNU General Public License. (This clause * is necessary due to a potential bad interaction between the GPL and * the restrictions contained in a BSD-style copyright.) * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, and the entire permission notice in its entirety, * including the disclaimer of warranties. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. The name of the author may not be used to endorse or promote * products derived from this software without specific prior * written permission. * Anyone interested in working/collaborating on a port? :-) [I am currently shopping for a laptop and will probably acquire one in the next month] --Jason j.b.georgeieee.org jbgmasterplan.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message From owner-freebsd-mobile Sat Jan 23 08:26:46 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA17521 for freebsd-mobile-outgoing; Sat, 23 Jan 1999 08:26:46 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from baynet.baynetworks.com (ns1.BayNetworks.COM [134.177.3.20]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA17516 for ; Sat, 23 Jan 1999 08:26:44 -0800 (PST) (envelope-from bwithrow@engeast.BayNetworks.COM) Received: from mailhost.BayNetworks.COM (h016b.s86b1.BayNetworks.COM [134.177.1.107]) by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id IAA17480; Sat, 23 Jan 1999 08:26:14 -0800 (PST) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id IAA18866; Sat, 23 Jan 1999 08:26:33 -0800 (PST) Received: from tuva.engeast.baynetworks.com (tuva [192.32.68.38]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id LAA12608; Sat, 23 Jan 1999 11:26:31 -0500 for Received: from tuva.engeast.baynetworks.com (localhost [127.0.0.1]) by tuva.engeast.baynetworks.com (8.8.8/8.8.8) with ESMTP id QAA29707; Sat, 23 Jan 1999 16:26:11 GMT (envelope-from bwithrow@tuva.engeast.baynetworks.com) Message-Id: <199901231626.QAA29707@tuva.engeast.baynetworks.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Jason George cc: freebsd-mobile@FreeBSD.ORG Subject: Re: Xircom PCMCIA driver In-Reply-To: Message from Jason George of "Fri, 22 Jan 1999 16:47:36 MST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 23 Jan 1999 11:26:10 -0500 From: Robert Withrow Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I was negotiating with Xircom to get the specs and all, and I though I was all set, then they stopped "talking" to me... I'd help, but only if I have the Xircom specs/programming guide. -- Robert Withrow -- (+1 978 916 8256) BWithrow@BayNetworks.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message