From owner-freebsd-mobile Sun Sep 21 04:43:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA27077 for mobile-outgoing; Sun, 21 Sep 1997 04:43:29 -0700 (PDT) Received: from hda.hda.com (hda-bicnet.bicnet.net [208.220.66.37]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA27070; Sun, 21 Sep 1997 04:43:24 -0700 (PDT) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id GAA10476; Sun, 21 Sep 1997 06:55:26 -0400 (EDT) From: Peter Dufault Message-Id: <199709211055.GAA10476@hda.hda.com> Subject: Re: IBM ThinkPad 365X In-Reply-To: <199709191947.MAA03244@hub.freebsd.org> from "Jonathan M. Bresler" at "Sep 19, 97 12:47:12 pm" To: jmb@FreeBSD.ORG (Jonathan M. Bresler) Date: Sun, 21 Sep 1997 06:55:25 -0400 (EDT) Cc: mobile@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-mobile@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > anyone used an IBM Think Pad 365X for FreeBSD? > it is not listed in hte PAO web pages. hmm... > http://www.jp.freebsd.org/PAO/latest/docs/LAPTOP_SURVEY/LTS.txt I'm using one a lot, and I filled out that survey. I guess it is still in the in box. Mine is a bit different from what you specify in that it has 810MB disk and the smaller 10.5" TFT instead of the 11.3" DSTN (I prefer the smaller TFT over the bigger DSTN). Probably if you wait another month the next generation will be at the discounters. The rest is the same and it works fine. One warning - set up a configuration disk before nuking all traces of w95 or you'll have to painfully construct a boot disk with stuff off the net not intended to work that way. There is no config in the BIOS. It was $1300 with additional 16MB memory and 3c589 ethernet. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval From owner-freebsd-mobile Tue Sep 23 12:30:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA29360 for mobile-outgoing; Tue, 23 Sep 1997 12:30:16 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA29304; Tue, 23 Sep 1997 12:29:40 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id NAA23638; Tue, 23 Sep 1997 13:29:37 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id NAA08312; Tue, 23 Sep 1997 13:29:37 -0600 (MDT) Date: Tue, 23 Sep 1997 13:29:37 -0600 (MDT) Message-Id: <199709231929.NAA08312@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: mobile@freebsd.org, current@freebsd.org CC: se@freebsd.org Subject: PCCARD in -current broken X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-mobile@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [ Forgive the cross-posting, the information is of interest to a number of folks. ] It has been for some time (May). If it works on your box, you're lucky! (PHK is one of the lucky ones, and it may be related to using more PCI-like machines, unlike older 'straight-ISA' laptops). The change to the 'generic' shared interrupt code broke some assumptions I had about 'register_intr()' and 'unregister_intr()' in /sys/pccard/pcic.c. Basically, I had assumed the register_intr() would fail if I wanted access to an interrupt that was already taken, and now it succeeds so I add it to my list of 'available' IRQ's (I'd give it back, but at this point the freemask is really hosed). This assumption leads to all sorts of problems, of which I haven't completely thought about. In any case, until the code in /sys/kern/kern_intr.c ifdef'd out by 'RESOURCE_CHECK' is finished, or something else is done to make sure that 'ISA/Exclusive' interrupts are not allowed to be registered as 'shared' resources, I think there are potential problems with the current scheme, and may even effect 'normal' (non-laptop) systems who use ISA devices, though it's doubtful they do silly things like I'm doing in the PCCARD code. I don't have any solutions in the short-term, but I wanted to let folks know about the possible problems. Nate ps. The code in 2.2.* is not affected, since the new interrupt code only lives in -current. From owner-freebsd-mobile Tue Sep 23 15:32:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA09615 for mobile-outgoing; Tue, 23 Sep 1997 15:32:55 -0700 (PDT) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA09564; Tue, 23 Sep 1997 15:32:42 -0700 (PDT) Received: from x14.mi.uni-koeln.de ([134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA18866 (5.67b/IDA-1.5); Wed, 24 Sep 1997 00:32:39 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id XAA04079; Tue, 23 Sep 1997 23:00:19 +0200 (CEST) X-Face: " Date: Tue, 23 Sep 1997 23:00:18 +0200 From: Stefan Esser To: Nate Williams Cc: mobile@FreeBSD.ORG, current@FreeBSD.ORG, Stefan Esser Subject: Re: PCCARD in -current broken References: <199709231929.NAA08312@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <199709231929.NAA08312@rocky.mt.sri.com>; from Nate Williams on Tue, Sep 23, 1997 at 01:29:37PM -0600 Sender: owner-freebsd-mobile@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sep 23, Nate Williams wrote: > It has been for some time (May). If it works on your box, you're > lucky! (PHK is one of the lucky ones, and it may be related to using > more PCI-like machines, unlike older 'straight-ISA' laptops). Hmmm, I'm surprised to hear that ... You are the first to report such a problem. > The change to the 'generic' shared interrupt code broke some assumptions > I had about 'register_intr()' and 'unregister_intr()' in > /sys/pccard/pcic.c. Basically, I had assumed the register_intr() would > fail if I wanted access to an interrupt that was already taken, and now > it succeeds so I add it to my list of 'available' IRQ's (I'd give it > back, but at this point the freemask is really hosed). This assumption > leads to all sorts of problems, of which I haven't completely thought > about. There should not be a problem. ISA does not (should not, I didn't check the sources recently) register the handler as shared, and this will prevent another handler (both shared or exclusive) to be registered. I assume this does not work for you ? > In any case, until the code in /sys/kern/kern_intr.c ifdef'd out by > 'RESOURCE_CHECK' is finished, or something else is done to make sure The code is finished, but I did not commit it to -current, since I was waiting for the new ISA device probe/attach code to become available. Several concepts have been discussed, with the "extent registration" of NetBSD being mentioned very often. My concept is quite different, in that I'd rather have a functional interface, which works on bus-dependent data structures that have to exist anyway, while the extent data does exist independently of device data. I have outlined this before ... > that 'ISA/Exclusive' interrupts are not allowed to be registered as > 'shared' resources, I think there are potential problems with the Well, ISA interrupts should be registered in a way that guarantees they are not shared. > current scheme, and may even effect 'normal' (non-laptop) systems who > use ISA devices, though it's doubtful they do silly things like I'm > doing in the PCCARD code. > > I don't have any solutions in the short-term, but I wanted to let folks > know about the possible problems. Hmmm, I just checked the sources and I can't see what's wrong. Please tell me why the following is not sufficient: config_isadev_c() calls register_intr() register_intr() contains the following lines: flags |= INTR_EXCL; idesc = intr_create((void *)device_id, intr, handler, (void*)unit, maskptr, flags); return (intr_connect(idesc)); intr_create() just stores the flag in the interrupt descriptor, intr_connect() calls add_intrdesc(), which has: if ((idesc->flags & INTR_EXCL) != 0 || (head->flags & INTR_EXCL) != 0) { /* * can't append new handler, if either list head or * new handler do not allow interrupts to be shared */ printf("\tdevice combination doesn't support shared irq%d\n", irq); return (-1); } As soon as some ISA device got an interrupt registered, no second handler will be added. I've checked, that pccard.c also uses the register_intr() compatibility call, and thus it will also get INTR_EXCL added to the flags value supplied (which is a constant "0"). Please tell me what's wrong with this ... Regards, STefan From owner-freebsd-mobile Tue Sep 23 15:47:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA10657 for mobile-outgoing; Tue, 23 Sep 1997 15:47:55 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA10615; Tue, 23 Sep 1997 15:47:30 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id QAA24930; Tue, 23 Sep 1997 16:46:58 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id QAA09189; Tue, 23 Sep 1997 16:46:56 -0600 (MDT) Date: Tue, 23 Sep 1997 16:46:56 -0600 (MDT) Message-Id: <199709232246.QAA09189@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Stefan Esser Cc: Nate Williams , mobile@freebsd.org, current@freebsd.org Subject: Re: PCCARD in -current broken In-Reply-To: <19970923230018.00034@mi.uni-koeln.de> References: <199709231929.NAA08312@rocky.mt.sri.com> <19970923230018.00034@mi.uni-koeln.de> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-mobile@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > It has been for some time (May). If it works on your box, you're > > lucky! (PHK is one of the lucky ones, and it may be related to using > > more PCI-like machines, unlike older 'straight-ISA' laptops). > > Hmmm, I'm surprised to hear that ... > You are the first to report such a problem. Most folks don't use current on their laptops. :) > > The change to the 'generic' shared interrupt code broke some assumptions > > I had about 'register_intr()' and 'unregister_intr()' in > > /sys/pccard/pcic.c. Basically, I had assumed the register_intr() would > > fail if I wanted access to an interrupt that was already taken, and now > > it succeeds so I add it to my list of 'available' IRQ's (I'd give it > > back, but at this point the freemask is really hosed). This assumption > > leads to all sorts of problems, of which I haven't completely thought > > about. > > There should not be a problem. ISA does not > (should not, I didn't check the sources > recently) register the handler as shared, > and this will prevent another handler (both > shared or exclusive) to be registered. register_intr() sets the INTR_EXCL flag just before it calls intr_create() (so far so good), but in intr_connect(), the code to check for that flag is ifdef's out: int intr_connect(intrec *idesc) { ... #ifdef RESOURCE_CHECK int resflag; #endif /* RESOURCE_CHECK */ .... #ifdef RESOURCE_CHECK resflag = (idesc->flags & INTR_EXCL) ? RESF_NONE : RESF_SHARED; if (resource_claim(idesc->devdata, REST_INT, resflag, irq, irq) == 0) #endif /* RESOURCE_CHECK */ { So, we don't even check to see if INTR_EXCL is used. > I assume this does not work for you ? See above. > > In any case, until the code in /sys/kern/kern_intr.c ifdef'd out by > > 'RESOURCE_CHECK' is finished, or something else is done to make sure > > The code is finished, but I did not commit > it to -current, since I was waiting for the > new ISA device probe/attach code to become > available. How does the new code realize that the interrupt is exclusive then? > > that 'ISA/Exclusive' interrupts are not allowed to be registered as > > 'shared' resources, I think there are potential problems with the > > Well, ISA interrupts should be registered in > a way that guarantees they are not shared. How? > Hmmm, I just checked the sources and I can't > see what's wrong. Please tell me why the > following is not sufficient: Hmm, never mind. I never walked enough down into the sources to see what's going on. So, can I rely on register_intr() return a negative # for failure? (Here's the code in question.) static u_int build_freelist(u_int pcic_mask) { inthand2_t *nullfunc; int irq; u_int mask, freemask; /* No free IRQs (yet). */ freemask = 0; /* Walk through all of the IRQ's and find any that aren't allocated. */ for (irq = 0; irq < ICU_LEN; irq++) { /* * If the PCIC controller can't generate it, don't * bother checking to see if it it's free. */ mask = 1 << irq; if (!(mask & pcic_mask)) continue; /* See if the IRQ is free. */ if (register_intr(irq, 0, 0, nullfunc, NULL, irq) == 0) { /* Give it back, but add it to the mask */ INTRMASK(freemask, mask); unregister_intr(irq, nullfunc); } } #ifdef PCIC_DEBUG printf("Freelist of IRQ's <0x%x>\n", freemask); #endif return freemask; } > Please tell me what's wrong with this ... Maybe nothing, and maybe I'm a geek who likes to blame everyone else for my problems! :( Nate From owner-freebsd-mobile Tue Sep 23 19:17:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA22138 for mobile-outgoing; Tue, 23 Sep 1997 19:17:22 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA22122; Tue, 23 Sep 1997 19:17:12 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id TAA05504; Tue, 23 Sep 1997 19:17:11 -0700 (PDT) Message-ID: <19970923191710.61639@hydrogen.nike.efn.org> Date: Tue, 23 Sep 1997 19:17:10 -0700 From: John-Mark Gurney To: Stefan Esser Cc: Nate Williams , mobile@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: PCCARD in -current broken References: <199709231929.NAA08312@rocky.mt.sri.com> <19970923230018.00034@mi.uni-koeln.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <19970923230018.00034@mi.uni-koeln.de>; from Stefan Esser on Tue, Sep 23, 1997 at 11:00:18PM +0200 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-mobile@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Stefan Esser scribbled this message on Sep 23: > > In any case, until the code in /sys/kern/kern_intr.c ifdef'd out by > > 'RESOURCE_CHECK' is finished, or something else is done to make sure > > The code is finished, but I did not commit > it to -current, since I was waiting for the > new ISA device probe/attach code to become > available. oh... if your waiting for the work that I'm working on.. commit the changes now.. I don't think that I'll have anything workable in the next month... as next monday is the first day of classes, and I've been working this week... so I haven't made any progress yet... > Several concepts have been discussed, with > the "extent registration" of NetBSD being > mentioned very often. > > My concept is quite different, in that I'd > rather have a functional interface, which > works on bus-dependent data structures that > have to exist anyway, while the extent data > does exist independently of device data. have you actually looked at the extent stuff from NetBSD?? you still have to write the wrappers around the extent to use the resources, it's just that it provides a way to do mapping of sections of units... > I have outlined this before ... > > > that 'ISA/Exclusive' interrupts are not allowed to be registered as > > 'shared' resources, I think there are potential problems with the > > Well, ISA interrupts should be registered in > a way that guarantees they are not shared. I agree.. but this should be on a bus dependant side... and with the new isa_device stuff I have invisioned.... we will be able to do more dynamic sharing of irqs... suchs as marking irqs as only used when device is active... so you can share irqs between devices... i.e. the common com1/com3 problem... ttyl.. -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-mobile Wed Sep 24 00:11:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA09957 for mobile-outgoing; Wed, 24 Sep 1997 00:11:54 -0700 (PDT) Received: from schizo.dk.tfs.com (mail.trw.dk [195.8.133.123]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA09923; Wed, 24 Sep 1997 00:11:46 -0700 (PDT) Received: from critter.freebsd.dk (critter.dk.tfs.com [140.145.230.252]) by schizo.dk.tfs.com (8.8.7/8.7.3) with ESMTP id JAA27083; Wed, 24 Sep 1997 09:11:14 +0200 (MET DST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id IAA00234; Wed, 24 Sep 1997 08:09:59 +0200 (CEST) To: Nate Williams cc: mobile@freebsd.org, current@freebsd.org, se@freebsd.org Subject: Re: PCCARD in -current broken In-reply-to: Your message of "Tue, 23 Sep 1997 13:29:37 MDT." <199709231929.NAA08312@rocky.mt.sri.com> Date: Wed, 24 Sep 1997 08:09:59 +0200 Message-ID: <232.875081399@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-mobile@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199709231929.NAA08312@rocky.mt.sri.com>, Nate Williams writes: >[ >Forgive the cross-posting, the information is of interest to a number >of folks. >] > >It has been for some time (May). If it works on your box, you're >lucky! (PHK is one of the lucky ones, and it may be related to using >more PCI-like machines, unlike older 'straight-ISA' laptops). Maybe I'm just suffering from from luck and too much knowledge: This is how it works for me: in pccard.conf: #IBM PCMCIA Ethernet I/II card "IBM Corp." "Ethernet" config 0x1 "ed0" 9 ^^^^^ As you can see I hardcode the irq of my card. from dmesg: pcic0: rev 0x04 int a irq 255 on pci0.4.0 pcic1: rev 0x04 int b irq 255 on pci0.4.1 [...] PC-Card VLSI 82C146 (5 mem & 2 I/O windows) pcic: controller irq 3 irq 3 happens to be free... -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-mobile Wed Sep 24 03:56:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA22191 for mobile-outgoing; Wed, 24 Sep 1997 03:56:12 -0700 (PDT) Received: from hda.hda.com (hda-bicnet.bicnet.net [208.220.66.37]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA22180 for ; Wed, 24 Sep 1997 03:56:08 -0700 (PDT) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id GAA19725; Wed, 24 Sep 1997 06:07:36 -0400 (EDT) From: Peter Dufault Message-Id: <199709241007.GAA19725@hda.hda.com> Subject: Re: ARRGH! NUM-Lock!!! In-Reply-To: <199709192319.JAA06366@noether.blah.org> from Ada Lim at "Sep 20, 97 09:19:28 am" To: ada@not-enough.bandwidth.org (Ada Lim) Date: Wed, 24 Sep 1997 06:07:35 -0400 (EDT) Cc: handy@sag.space.lockheed.com, mobile@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-mobile@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > D'uh. I can't figure it out. It seems like somehow I need to turn on the > > numeric keypad on my thinkpad, which is done via a -Scroll-lock. > > This turns the middle portion of the keyboard into a keypad, replete with > > the "-" and "+" keys. > Wait... this works perfectly on my 760 - I can press shift-scroll-lock, > the little numlock symbol comes up, and my screen changes mode under X. I gave this a try on my 365x - shift-scroll-lock works fine on a console and enables the numeric keypad but beeps under X. If I turn it on in a console screen and then switch back to the X screen something is smart enough to restore the original setting. What's the secret to keeping X from intercepting shift-scroll-lock? -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval From owner-freebsd-mobile Wed Sep 24 07:15:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA00647 for mobile-outgoing; Wed, 24 Sep 1997 07:15:39 -0700 (PDT) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id HAA00598; Wed, 24 Sep 1997 07:15:30 -0700 (PDT) Received: from x14.mi.uni-koeln.de ([134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA16896 (5.67b/IDA-1.5); Wed, 24 Sep 1997 16:12:57 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id OAA01092; Wed, 24 Sep 1997 14:47:45 +0200 (CEST) X-Face: " Date: Wed, 24 Sep 1997 14:47:44 +0200 From: Stefan Esser To: Nate Williams Cc: mobile@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: PCCARD in -current broken References: <199709231929.NAA08312@rocky.mt.sri.com> <19970923230018.00034@mi.uni-koeln.de> <199709232246.QAA09189@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <199709232246.QAA09189@rocky.mt.sri.com>; from Nate Williams on Tue, Sep 23, 1997 at 04:46:56PM -0600 Sender: owner-freebsd-mobile@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sep 23, Nate Williams wrote: > > There should not be a problem. ISA does not > > (should not, I didn't check the sources > > recently) register the handler as shared, > > and this will prevent another handler (both > > shared or exclusive) to be registered. > > register_intr() sets the INTR_EXCL flag just before it calls > intr_create() (so far so good), but in intr_connect(), the code to check > for that flag is ifdef's out: Well, I have implemented experimental resource registration and check code, but come to the conclusion, that it should be done quite differently ... > int > intr_connect(intrec *idesc) > { > .... > #ifdef RESOURCE_CHECK > resflag = (idesc->flags & INTR_EXCL) ? RESF_NONE : RESF_SHARED; > if (resource_claim(idesc->devdata, REST_INT, resflag, irq, irq) == 0) > #endif /* RESOURCE_CHECK */ > { > > So, we don't even check to see if INTR_EXCL is used. Well, you don't. I do, but I don't rely on that check :) > How does the new code realize that the interrupt is exclusive then? I have implemented a very simple set of functions to claim and check resource usage, and you see the resource_claim() call above. (The code does know resource types (e.g. REST_INT is interrupt), the minimum and maximum value (both passed as "irq" in the example), and a flag that currently only takes the value RESF_SHARED, if a resource may be shared with other uses, as long as all of them have RESF_SHARED set. > > Well, ISA interrupts should be registered in > > a way that guarantees they are not shared. > > How? But the code in -current does not use this function, and to make sure, that no other interrupt is added in combination with an exclusive interrupt, there is the test in add_intrdesc(), which I outlined in my previous reply. > So, can I rely on register_intr() return a negative # for failure? Well, if it fails for you, then there definitely is a bug in the check I added to add_intrdesc(), which is there to avoid just this situation. I assume you are sure that the PCCARD code is only called after the ISA devices are attached ? > (Here's the code in question.) > static u_int > build_freelist(u_int pcic_mask) > { > inthand2_t *nullfunc; > int irq; > u_int mask, freemask; > > /* No free IRQs (yet). */ > freemask = 0; > > /* Walk through all of the IRQ's and find any that aren't allocated. */ > for (irq = 0; irq < ICU_LEN; irq++) { > /* > * If the PCIC controller can't generate it, don't > * bother checking to see if it it's free. > */ > mask = 1 << irq; > if (!(mask & pcic_mask)) continue; > > /* See if the IRQ is free. */ > if (register_intr(irq, 0, 0, nullfunc, NULL, irq) == 0) { > /* Give it back, but add it to the mask */ > INTRMASK(freemask, mask); > unregister_intr(irq, nullfunc); > } > } > #ifdef PCIC_DEBUG > printf("Freelist of IRQ's <0x%x>\n", freemask); > #endif > return freemask; > } Looks fine to me. Lets see what happens after you call register_intr(): [ Much simplified extract from /sys/kern/kern_intr.c ! ] /** INTR_EXCL is added to flags and passed to intr_create(). **/ int register_intr(int intr, int device_id, u_int flags, inthand2_t handler, u_int *maskptr, int unit) { flags |= INTR_EXCL; idesc = intr_create((void *)device_id, intr, handler, (void*)unit, maskptr, flags); return (intr_connect(idesc)); } /** The flags parameter is put into the idesc structure. **/ intrec * intr_create(void *dev_instance, int irq, inthand2_t handler, void *arg, intrmask_t *maskptr, int flags) { idesc = malloc(sizeof *idesc, M_DEVBUF, M_WAITOK); if (idesc) { idesc->flags = flags; } return (idesc); } /** Return the error code from add_intrdesc (rest of code not shown). **/ int intr_connect(intrec *idesc) { errcode = add_intrdesc(idesc); return (errcode); } /** If this is the first handler for this irq, just register it. **/ /** If another handler has been registered before, then make sure, **/ /** that both the old and new handler are for a device that supports **/ /** shared interrupts (does not have INTR_EXCL set). Only the first **/ /** handler can have INTR_EXCL set, since no second one could have **/ /** been added ... **/ static int add_intrdesc(intrec *idesc) { if (head == NULL) { /* first handler for this irq, just install it */ if (icu_setup(irq, idesc->handler, idesc->argument, idesc->maskptr, idesc->flags) != 0) return (-1); } else { if ((idesc->flags & INTR_EXCL) != 0 || (head->flags & INTR_EXCL) != 0) { /* * can't append new handler, if either list head or * new handler do not allow interrupts to be shared */ printf("\tdevice combination doesn't support shared irq%d\n", irq); return (-1); } /* DO REAL WORK */ } return (0); } Well, in fact you should see the "device combination doesn't support ..." message printed, when you call register_intr() to check for the interrupt to be available. If you don't then there is a good chance, that you perform this test, before the ISA devices are attached, and there is no collision reported until the PCCARD attach tries to register a handler for an assumed free IRQ, which has been claimed by an ISA driver in between ... Regards, Stefan From owner-freebsd-mobile Wed Sep 24 07:15:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA00690 for mobile-outgoing; Wed, 24 Sep 1997 07:15:55 -0700 (PDT) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id HAA00605; Wed, 24 Sep 1997 07:15:31 -0700 (PDT) Received: from x14.mi.uni-koeln.de ([134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA16893 (5.67b/IDA-1.5); Wed, 24 Sep 1997 16:12:54 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id PAA01285; Wed, 24 Sep 1997 15:53:02 +0200 (CEST) X-Face: " Date: Wed, 24 Sep 1997 15:53:02 +0200 From: Stefan Esser To: John-Mark Gurney Cc: Nate Williams , mobile@FreeBSD.ORG, current@FreeBSD.ORG, Stefan Esser Subject: Re: PCCARD in -current broken References: <199709231929.NAA08312@rocky.mt.sri.com> <19970923230018.00034@mi.uni-koeln.de> <19970923191710.61639@hydrogen.nike.efn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <19970923191710.61639@hydrogen.nike.efn.org>; from John-Mark Gurney on Tue, Sep 23, 1997 at 07:17:10PM -0700 Sender: owner-freebsd-mobile@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sep 23, John-Mark Gurney wrote: > > The code is finished, but I did not commit > > it to -current, since I was waiting for the > > new ISA device probe/attach code to become > > available. > > oh... if your waiting for the work that I'm working on.. commit the > changes now.. I don't think that I'll have anything workable in the > next month... as next monday is the first day of classes, and I've been > working this week... so I haven't made any progress yet... Well, as I wrote before, I do not intend to commit that resource check code, since I do no longer consider it the correct approach. I rather want to have a "generic" device struct, which is common to all device types (including, for example, SCSI drives), and which offers a few pointers to methods, upper data structures (i.e. driver and bus specific) and device parameters. (Very much like the Ethernet drivers do, BTW.) I'd expect to be able to call a bus-specific function that allows me to check the resource usage of a device. A function prototype might be: res_check(gendev *dev, int res_type, int flags) This function could redirect the call through a function pointer obtained from dev->xxx and that function could for PCI support res_type values of memory range, port range, IRQ set and DRQ set. The SCSI code should provide a function that checked the SCSI ID. The flags parameter could be used to mark a registration as "shared", or to allow to check for not yet registered but prefered resources of some ISA PnP card. The "extent" registration code from NetBSD is quite generic, and could be used to register the resource usage. But I prefer to query the device data directly, instead of duplicating the information in some generic data base. The device private data contains all the information about the resource usage in a way that allows to represent sparse data (like the set of IRQs or DMA channels used). It is also easy to check for resources this device would use, if it was attached. This may be of use in code that plans address ranges for ISA PnP devices that can be mapped to certain addresses. No need to register a resource, BTW. As soon as the device struct is available to the probe code (either as a DATA_SET or the isa_devtab_xxx array), the device's data is available to the resource check functions. Only the device state has to be set (unused, attached, possibly intermediate states). The test for resource usage would search through the bus and device tree, but in many cases the search of a subtree can be avoided (e.g. a PCI to PCI bridge will claim all address ranges it maps to the secondary side, and thus only devices on a PCI bus directly connected to the CPU have to be checked. This reduces the number of tests that have to be performed in a system with lots of devices. I do not expect the checking against device private data to be much more inefficient than a extent registry, and it is done at driver probe/attach time only, anyway. Other information in this generic device struct should be a unit number and an up pointer to the driver structure (again at least partially generic), which among function pointers contains the driver name. This would allow to build device names for all devices in a uniform way, for example for the reservation conflict message in res_check() ... :) I have put some effort in working out the details, but those changes are of no big use, if they are not applied to all device types (i.e. ISA/EISA/ PCI-Buses, card drivers for these buses, SCSI device drivers, SCSI device structures). > have you actually looked at the extent stuff from NetBSD?? you still > have to write the wrappers around the extent to use the resources, it's > just that it provides a way to do mapping of sections of units... Yes, sure. And I have a simple registration data base in my kernel, which does just register the resource usage. What I do not like about it is: 1) I have to register all resources at attach time and to unregister them when the device is shutdown. I'd rather flip just a single bit in the device data structure, which has to contain all the information anyway. 2) The extent code is "tagged on to the side", and I'd rather just define the prototype of the check function and let each bus driver provide an implementation that complies with the definition. > > Well, ISA interrupts should be registered in > > a way that guarantees they are not shared. > I agree.. but this should be on a bus dependant side... and with the > new isa_device stuff I have invisioned.... we will be able to do more > dynamic sharing of irqs... suchs as marking irqs as only used when > device is active... so you can share irqs between devices... i.e. the > common com1/com3 problem... But the code that makes ISA interrupts exclusive is in a bus dependent function (at least I consider the old register_intr() function to be ISA specific). All new code should only use intr_create(), which creates an interrupt descriptor, and intr_connect() and intr_disconnect() which (in)activates the handler according to the information in that descriptor. (BTW: Connecting or disconnecting the handler does not require a check for conflicts, since the function that manages the shared interrupt handler chain does check for conflicts whenever a handler is added.) The new ISA code definitely should use that interface, and no longer call register_intr() ... Regards, STefan From owner-freebsd-mobile Wed Sep 24 08:27:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA04725 for mobile-outgoing; Wed, 24 Sep 1997 08:27:13 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA04700; Wed, 24 Sep 1997 08:27:03 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id JAA01010; Wed, 24 Sep 1997 09:27:01 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id JAA12203; Wed, 24 Sep 1997 09:26:59 -0600 (MDT) Date: Wed, 24 Sep 1997 09:26:59 -0600 (MDT) Message-Id: <199709241526.JAA12203@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Stefan Esser Cc: Nate Williams , mobile@freebsd.org, current@freebsd.org Subject: Re: PCCARD in -current broken In-Reply-To: <19970924144744.47293@mi.uni-koeln.de> References: <199709231929.NAA08312@rocky.mt.sri.com> <19970923230018.00034@mi.uni-koeln.de> <199709232246.QAA09189@rocky.mt.sri.com> <19970924144744.47293@mi.uni-koeln.de> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-mobile@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I assume you are sure that the PCCARD code is only > called after the ISA devices are attached ? In autoconf.c/configure: #if NEISA > 0 eisa_configure(); #endif #if NPCI > 0 pci_configure(); #endif #if NISA > 0 isa_configure(); #endif #if NCRD > 0 /* After everyone else has a chance at grabbing resources */ pccard_configure(); #endif > Well, in fact you should see the "device combination doesn't support ..." > message printed, when you call register_intr() to check for the interrupt > to be available. Hmm, do mobile users see these messages who run -current? > If you don't then there is a good chance, that you perform > this test, before the ISA devices are attached, and there is no collision > reported until the PCCARD attach tries to register a handler for an assumed > free IRQ, which has been claimed by an ISA driver in between ... That shouldn't happen (given the code in autoconf.) Sorry for the false alarm, back to the drawing board. Nate From owner-freebsd-mobile Wed Sep 24 08:36:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA05311 for mobile-outgoing; Wed, 24 Sep 1997 08:36:01 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA05285; Wed, 24 Sep 1997 08:35:55 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id BAA01330; Thu, 25 Sep 1997 01:33:16 +1000 Date: Thu, 25 Sep 1997 01:33:16 +1000 From: Bruce Evans Message-Id: <199709241533.BAA01330@godzilla.zeta.org.au> To: nate@mt.sri.com, se@FreeBSD.ORG Subject: Re: PCCARD in -current broken Cc: current@FreeBSD.ORG, mobile@FreeBSD.ORG Sender: owner-freebsd-mobile@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >On Sep 23, Nate Williams wrote: >>... >> So, can I rely on register_intr() return a negative # for failure? No, it sometimes returns > 0 for failure, sometimes -1. This is incompatible with the old register_intr(), which always returned > 0 (e.g., EBUSY) for failure. >Well, if it fails for you, then there definitely is >a bug in the check I added to add_intrdesc(), which >is there to avoid just this situation. pccard arctually checks for != 0 for failure, so it should have no problems with this incompatibilty. >Looks fine to me. Lets see what happens after you call >register_intr(): >... >Well, in fact you should see the "device combination doesn't support ..." >message printed, when you call register_intr() to check for the interrupt >to be available. If you don't then there is a good chance, that you perform This part works fine :-). I see these messages a lot because I register some interrupts in drivers and isa_configure() attempts to register them again. Bruce From owner-freebsd-mobile Wed Sep 24 11:24:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA16180 for mobile-outgoing; Wed, 24 Sep 1997 11:24:38 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA16165; Wed, 24 Sep 1997 11:24:28 -0700 (PDT) Received: from Mercury.mcs.net (fredriks@Mercury.mcs.net [192.160.127.80]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id NAA24414; Wed, 24 Sep 1997 13:24:26 -0500 (CDT) Received: (from fredriks@localhost) by Mercury.mcs.net (8.8.7/8.8.2) id NAA19380; Wed, 24 Sep 1997 13:24:26 -0500 (CDT) From: Lars Fredriksen Message-Id: <199709241824.NAA19380@Mercury.mcs.net> Subject: Re: PCCARD in -current broken To: nate@mt.sri.com (Nate Williams) Date: Wed, 24 Sep 1997 13:24:24 -0500 (CDT) Cc: se@FreeBSD.ORG, nate@mt.sri.com, mobile@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: <199709241526.JAA12203@rocky.mt.sri.com> from "Nate Williams" at Sep 24, 97 09:26:59 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-mobile@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Nate Williams writes: > > > I assume you are sure that the PCCARD code is only > > called after the ISA devices are attached ? > > In autoconf.c/configure: > #if NEISA > 0 > eisa_configure(); > #endif > > #if NPCI > 0 > pci_configure(); > #endif > > #if NISA > 0 > isa_configure(); > #endif > > #if NCRD > 0 > /* After everyone else has a chance at grabbing resources */ > pccard_configure(); > #endif > > > Well, in fact you should see the "device combination doesn't support ..." > > message printed, when you call register_intr() to check for the interrupt > > to be available. > > Hmm, do mobile users see these messages who run -current? Yes, I do see that message. That is when I decided that the interrupt registration is handeled correctly, but that the intrnames array seems not to be maintained correctly. This is where the clk0 gets associated with the irq of the driver that pcic registered when it detected a card and found a driver match. I do probably need to mention that this is on a i486 laptop..... Lars -- ------------------------------------------------------------------- Lars Fredriksen fredriks@mcs.com (home) lars@fredriks-2.pr.mcs.net (home-home) From owner-freebsd-mobile Wed Sep 24 12:41:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA21360 for mobile-outgoing; Wed, 24 Sep 1997 12:41:19 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA21349; Wed, 24 Sep 1997 12:41:09 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id MAA09270; Wed, 24 Sep 1997 12:41:06 -0700 (PDT) Message-ID: <19970924124106.61317@hydrogen.nike.efn.org> Date: Wed, 24 Sep 1997 12:41:06 -0700 From: John-Mark Gurney To: Stefan Esser Cc: Nate Williams , mobile@freebsd.org, current@freebsd.org Subject: Re: PCCARD in -current broken References: <199709231929.NAA08312@rocky.mt.sri.com> <19970923230018.00034@mi.uni-koeln.de> <19970923191710.61639@hydrogen.nike.efn.org> <19970924155302.35730@mi.uni-koeln.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <19970924155302.35730@mi.uni-koeln.de>; from Stefan Esser on Wed, Sep 24, 1997 at 03:53:02PM +0200 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-mobile@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Stefan Esser scribbled this message on Sep 24: > On Sep 23, John-Mark Gurney wrote: > > > The code is finished, but I did not commit > > > it to -current, since I was waiting for the > > > new ISA device probe/attach code to become > > > available. > > > > oh... if your waiting for the work that I'm working on.. commit the > > changes now.. I don't think that I'll have anything workable in the > > next month... as next monday is the first day of classes, and I've been > > working this week... so I haven't made any progress yet... > > Well, as I wrote before, I do not intend to > commit that resource check code, since I do > no longer consider it the correct approach. > > I rather want to have a "generic" device > struct, which is common to all device types > (including, for example, SCSI drives), and > which offers a few pointers to methods, upper > data structures (i.e. driver and bus specific) > and device parameters. (Very much like the > Ethernet drivers do, BTW.) > > I'd expect to be able to call a bus-specific > function that allows me to check the resource > usage of a device. A function prototype might > be: > > res_check(gendev *dev, int res_type, int flags) > > This function could redirect the call through > a function pointer obtained from dev->xxx and > that function could for PCI support res_type > values of memory range, port range, IRQ set > and DRQ set. The SCSI code should provide a > function that checked the SCSI ID. The flags > parameter could be used to mark a registration > as "shared", or to allow to check for not yet > registered but prefered resources of some ISA > PnP card. > > The "extent" registration code from NetBSD is > quite generic, and could be used to register > the resource usage. But I prefer to query the > device data directly, instead of duplicating > the information in some generic data base. you haven't looked at the extent stuff from NetBSD... all it does is allows you to "mark" used portions of a number set (say [0,15] for IRQs) then you can quickly check to see if a resource is used... not who owns the resource... extent keeps no info on who owns a resource... just that a resource is used... > The device private data contains all the > information about the resource usage in a way > that allows to represent sparse data (like the > set of IRQs or DMA channels used). It is also yes.. it will... > easy to check for resources this device would > use, if it was attached. This may be of use in > code that plans address ranges for ISA PnP > devices that can be mapped to certain addresses. > > No need to register a resource, BTW. As soon as > the device struct is available to the probe code > (either as a DATA_SET or the isa_devtab_xxx array), > the device's data is available to the resource > check functions. Only the device state has to be > set (unused, attached, possibly intermediate > states). > > The test for resource usage would search through > the bus and device tree, but in many cases the > search of a subtree can be avoided (e.g. a PCI > to PCI bridge will claim all address ranges it > maps to the secondary side, and thus only devices > on a PCI bus directly connected to the CPU have > to be checked. This reduces the number of tests > that have to be performed in a system with lots > of devices. I do not expect the checking against > device private data to be much more inefficient > than a extent registry, and it is done at driver > probe/attach time only, anyway. yes.. but with the new dynamic loading code... the driver probe/attach will be done at any time.. plus.. the current implementation can have the conflicts to be double checked (i.e. it read the irq off the card and it didn't match the irq passed, so it puts in the new irq, tells it to reconfig the device)... plus.. how do you handle the finding of resources for a device?? say you need to memory map something in the 384k isa whole, want is aligned to some boundary, and don't want it to cross another boundary?? extent will handle this automaticly for you... > Other information in this generic device struct > should be a unit number and an up pointer to the > driver structure (again at least partially generic), > which among function pointers contains the driver > name. This would allow to build device names for > all devices in a uniform way, for example for the > reservation conflict message in res_check() ... :) this is one thing you couldn't do with extent is find who owns the resource... it would be nice.. you could do that once you've found that there is a conflict though... > I have put some effort in working out the details, > but those changes are of no big use, if they are > not applied to all device types (i.e. ISA/EISA/ > PCI-Buses, card drivers for these buses, SCSI > device drivers, SCSI device structures). > > > have you actually looked at the extent stuff from NetBSD?? you still > > have to write the wrappers around the extent to use the resources, it's > > just that it provides a way to do mapping of sections of units... > > Yes, sure. And I have a simple registration data > base in my kernel, which does just register the > resource usage. What I do not like about it is: > > 1) I have to register all resources at attach > time and to unregister them when the device > is shutdown. I'd rather flip just a single > bit in the device data structure, which has > to contain all the information anyway. > > 2) The extent code is "tagged on to the side", > and I'd rather just define the prototype of > the check function and let each bus driver > provide an implementation that complies with > the definition. umm... you do this.. it's just that the bus driver creates a private extent map for it's resources... extent doesn't do that much for you, it's just a set of functions that make writing the bus driver function all that much easier... > > > Well, ISA interrupts should be registered in > > > a way that guarantees they are not shared. > > > I agree.. but this should be on a bus dependant side... and with the > > new isa_device stuff I have invisioned.... we will be able to do more > > dynamic sharing of irqs... suchs as marking irqs as only used when > > device is active... so you can share irqs between devices... i.e. the > > common com1/com3 problem... > > But the code that makes ISA interrupts exclusive > is in a bus dependent function (at least I consider > the old register_intr() function to be ISA specific). > > All new code should only use intr_create(), which > creates an interrupt descriptor, and intr_connect() > and intr_disconnect() which (in)activates the handler > according to the information in that descriptor. > > (BTW: Connecting or disconnecting the handler does > not require a check for conflicts, since the function > that manages the shared interrupt handler chain does > check for conflicts whenever a handler is added.) hmm... I'll look at this code... > The new ISA code definitely should use that interface, > and no longer call register_intr() ... do you have any prototype structs of what you want things to look like.. one thing I'm lacking is experience with different bus designes... so making a truely generic structure is a bit more difficult for me... ttyl.. -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-mobile Wed Sep 24 14:23:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA28425 for mobile-outgoing; Wed, 24 Sep 1997 14:23:35 -0700 (PDT) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA28401; Wed, 24 Sep 1997 14:23:18 -0700 (PDT) Received: from x14.mi.uni-koeln.de ([134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA23089 (5.67b/IDA-1.5); Wed, 24 Sep 1997 23:23:08 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id XAA00666; Wed, 24 Sep 1997 23:11:30 +0200 (CEST) X-Face: " Date: Wed, 24 Sep 1997 23:11:29 +0200 From: Stefan Esser To: John-Mark Gurney Cc: Nate Williams , mobile@FreeBSD.ORG, current@FreeBSD.ORG, Stefan Esser Subject: Re: PCCARD in -current broken References: <199709231929.NAA08312@rocky.mt.sri.com> <19970923230018.00034@mi.uni-koeln.de> <19970923191710.61639@hydrogen.nike.efn.org> <19970924155302.35730@mi.uni-koeln.de> <19970924124106.61317@hydrogen.nike.efn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <19970924124106.61317@hydrogen.nike.efn.org>; from John-Mark Gurney on Wed, Sep 24, 1997 at 12:41:06PM -0700 Sender: owner-freebsd-mobile@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sep 24, John-Mark Gurney wrote: > > The "extent" registration code from NetBSD is > > quite generic, and could be used to register > > the resource usage. But I prefer to query the > > device data directly, instead of duplicating > > the information in some generic data base. > > you haven't looked at the extent stuff from NetBSD... all it does is Sure did I look at that code! It has been a few months ago, though. > allows you to "mark" used portions of a number set (say [0,15] for IRQs) > then you can quickly check to see if a resource is used... not who > owns the resource... extent keeps no info on who owns a resource... > just that a resource is used... Yes, I know this. It couldn't coalesce ranges, else. It offers faster lookup for a conflict, but I want to know what's causing a conflict, and for that reason I do not want to have resources registered anonymously. And before duplicating the information present in the driver in some registry, I prefer to directly use the information present in the driver private data. As I said before, the extent registration code allows for a faster check for a collision, but I'd rather be which driver conflicts with another one. Since the check will be performed at device attach time only, this should not cause problems. > yes.. but with the new dynamic loading code... the driver probe/attach > will be done at any time.. plus.. the current implementation can have > the conflicts to be double checked (i.e. it read the irq off the card > and it didn't match the irq passed, so it puts in the new irq, tells > it to reconfig the device)... plus.. how do you handle the finding of > resources for a device?? say you need to memory map something in the > 384k isa whole, want is aligned to some boundary, and don't want it to > cross another boundary?? extent will handle this automaticly for you... If a device has certain restrictions for addresses or other parameters, then the attach code should know about them. I agree, that the extent code simplifies finding a suitable address range in such a case. I was more interested in avoiding conflicts, and I'm willing to make the scan for an address region check all supported ranges against all registered devices. (Most ISA devices support only a very limited set of addresses, not as regular as you suggest above. The restrictions need not be (alignment, boundary to avoid), but often are some discrete tuples of values. IMHO, PnP ISA cards will actually be configured by the BIOS, if present. Else I expect a user land program to exist, which is able to query and calculate parameters to use for that card. The results should be stored in "boot.config" in text form. > > Other information in this generic device struct > > should be a unit number and an up pointer to the > > driver structure (again at least partially generic), > > which among function pointers contains the driver > > name. This would allow to build device names for > > all devices in a uniform way, for example for the > > reservation conflict message in res_check() ... :) > > this is one thing you couldn't do with extent is find who owns the > resource... it would be nice.. you could do that once you've found > that there is a conflict though... Hmmm, seems we approach these questions from quite opposite directions: You assume there is an extent registry, and see that per device resource checking could help identify the conflicting parties. I start with a desire to identify conflicting parties, if there are any, and think this is sufficient also if some address (or IRQ) has to be choosen to not conflict. (It may take several iterations, until a value is tried, that does not conflict, but I think this will take at most a few milliseconds per device that is attached and needs to find some non-conflicting value.) > umm... you do this.. it's just that the bus driver creates a private > extent map for it's resources... extent doesn't do that much for you, > it's just a set of functions that make writing the bus driver function > all that much easier... Well, in case of the PCI code, the PCI to PCI bridge provides "windows" from the primary to the secondary side. In a way, this is like an extent registration for the devices behind the bridge, but in fact, the windows are much more "real": They are stored in the "base" and "limit" registers of the bridge chip, and make the bridge appear as a device that decodes those addresses on the primary bus. A generic set of extent registration functions does not help here at all. And I doubt it does in other situations. Do you have "real" examples to the contrary ? > > The new ISA code definitely should use that interface, > > and no longer call register_intr() ... > > do you have any prototype structs of what you want things to look like.. > one thing I'm lacking is experience with different bus designes... so > making a truely generic structure is a bit more difficult for me... Well, I have a lot of details on paper, and I could start typing it in. I started looking at a device: - it is an instance with private variables - it is controlled by a driver, which has its own set of methods - it is attached in a bus specific way, the bus may be considered to be a "class" A bus may be considered as a device, which controls dependent devices. I'll need some time to find my notes about this, since they are in a big pile of papers and data books, about one meter in height :) One of my concerns was to find data structures, that are space efficient. I could make the PCI code use such structures, but as long as there is no support in the code for other buses, it doesn't provide any actual advantage. I'll forward an article I posted to the -current list in May to you in a seperate message. It is not what I ended with, though, but I do not have anything else in electronic form, right now ... Regards, STefan From owner-freebsd-mobile Thu Sep 25 09:52:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA28325 for mobile-outgoing; Thu, 25 Sep 1997 09:52:16 -0700 (PDT) Received: from word.smith.net.au (word.smith.net.au [202.0.75.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA28313 for ; Thu, 25 Sep 1997 09:52:08 -0700 (PDT) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id CAA04769 for ; Fri, 26 Sep 1997 02:19:57 +0930 (CST) Message-Id: <199709251649.CAA04769@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: mobile@freebsd.org Subject: Replacement dongle for 3C589? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Sep 1997 02:19:54 +0930 From: Mike Smith Sender: owner-freebsd-mobile@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Having just recovered my laptop after having had it stolen, I need to replace the dongle off the 3C589. I seem to recall stories about how hard this is - what experiences have people had with this? Anyone have a spare? 8) mike From owner-freebsd-mobile Thu Sep 25 10:25:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA00174 for mobile-outgoing; Thu, 25 Sep 1997 10:25:45 -0700 (PDT) Received: from coconut.itojun.org (root@coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA00169 for ; Thu, 25 Sep 1997 10:25:39 -0700 (PDT) From: itojun@itojun.org Received: from localhost (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.8.5/3.6Wbeta6) with ESMTP id CAA27991; Fri, 26 Sep 1997 02:25:14 +0900 (JST) To: Mike Smith cc: mobile@FreeBSD.ORG In-reply-to: mike's message of Fri, 26 Sep 1997 02:19:54 +0930. <199709251649.CAA04769@word.smith.net.au> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Replacement dongle for 3C589? Date: Fri, 26 Sep 1997 02:25:13 +0900 Message-ID: <27987.875208313@coconut.itojun.org> Sender: owner-freebsd-mobile@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Having just recovered my laptop after having had it stolen, I need to >replace the dongle off the 3C589. I seem to recall stories about how >hard this is - what experiences have people had with this? >Anyone have a spare? 8) At some of the stores in Tokyo area, you can buy the attachment cable for 3c589C/D alone. (I believe you mean this by "dongle"... I don't have "dongle" on my e-j dictionary) Therefore, I believe you can order one to 3com. However, the attachment cable costs almost $50, and brand-new ne2000-compatible PCMCIA card costs $70. Which do you choose? :-) itojun From owner-freebsd-mobile Thu Sep 25 10:38:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA01097 for mobile-outgoing; Thu, 25 Sep 1997 10:38:52 -0700 (PDT) Received: from word.smith.net.au (word.smith.net.au [202.0.75.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA01092 for ; Thu, 25 Sep 1997 10:38:48 -0700 (PDT) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id DAA04935; Fri, 26 Sep 1997 03:06:26 +0930 (CST) Message-Id: <199709251736.DAA04935@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: itojun@itojun.org cc: Mike Smith , mobile@FreeBSD.ORG Subject: Re: Replacement dongle for 3C589? In-reply-to: Your message of "Fri, 26 Sep 1997 02:25:13 +0900." <27987.875208313@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Sep 1997 03:06:24 +0930 From: Mike Smith Sender: owner-freebsd-mobile@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > >Having just recovered my laptop after having had it stolen, I need to > >replace the dongle off the 3C589. I seem to recall stories about how > >hard this is - what experiences have people had with this? > >Anyone have a spare? 8) > > At some of the stores in Tokyo area, you can buy the attachment > cable for 3c589C/D alone. > (I believe you mean this by "dongle"... I don't have "dongle" on my > e-j dictionary) Therefore, I believe you can order one to 3com. A "dongle" is a highly technical term for a thing that hangs off the end. Yes, I mean the MAU for the '589. 8) > However, the attachment cable costs almost $50, and brand-new > ne2000-compatible PCMCIA card costs $70. Which do you choose? :-) Hmm. Not so cheap here. Prices in Australian Dollars; which of these would you recommend for adventure? NewMedia $159 (BNC, TP) Hypertec $149 (BNC, TP) D-Link $138 (TP) Alloy $139 (BNC, TP) Eagle $119 (TP) Socket $119 (TP) Topware $139 (BNC) (I haven't called 3Com, if indeed they have an Australian spares agent.) mike From owner-freebsd-mobile Thu Sep 25 15:55:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA19476 for mobile-outgoing; Thu, 25 Sep 1997 15:55:45 -0700 (PDT) Received: from arg1.demon.co.uk (arg1.demon.co.uk [194.222.34.166]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA19464 for ; Thu, 25 Sep 1997 15:55:39 -0700 (PDT) Received: (from arg@localhost) by arg1.demon.co.uk (8.8.5/8.8.5) id XAA05212; Thu, 25 Sep 1997 23:54:50 +0100 (BST) Date: Thu, 25 Sep 1997 23:54:50 +0100 (BST) From: Andrew Gordon X-Sender: arg@server.arg.sj.co.uk To: Mike Smith cc: mobile@freebsd.org Subject: Re: Replacement dongle for 3C589? In-Reply-To: <199709251736.DAA04935@word.smith.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-mobile@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 26 Sep 1997, Mike Smith wrote: > > >Having just recovered my laptop after having had it stolen, I need to > > >replace the dongle off the 3C589. I seem to recall stories about how > > >hard this is - what experiences have people had with this? > > >Anyone have a spare? 8) I have a spare RJ45 cable for a 3C589A/B (having mis-typed the product code when attempting to order one for my 3C589_C_). You are welcome to it if it happens to be what you wanted. The RJ45 ones (both flavours) are quite cheap; the BNC ones are about 4 times the price (GBP 13 / GBP 48). > > However, the attachment cable costs almost $50, and brand-new > > ne2000-compatible PCMCIA card costs $70. Which do you choose? :-) > > Hmm. Not so cheap here. Prices in Australian Dollars; which of these > would you recommend for adventure? > > NewMedia $159 (BNC, TP) > Hypertec $149 (BNC, TP) > D-Link $138 (TP) > Alloy $139 (BNC, TP) > Eagle $119 (TP) > Socket $119 (TP) > Topware $139 (BNC) Are you sure all of these are NE2000 compatible? I have a NewMedia "livewire" card, which has AMD 79C940 chipset (having read the datasheet and discovered that it's completely different to the 79C960, I have given up on this one). I also have an Eagle NE200 - despite its seductively similar partnumber, this is _not_ NE2000 compatible. It has the Fujitsu MB86960 chipset; a quick attempt to make it go with the "fe" driver didn't work, though I haven't yet exhausted the configuration possibilities here (also, I may have broken it while prising off the lid to determine the chipset). > (I haven't called 3Com, if indeed they have an Australian spares agent.) The cables are available ex-stock from ordinary retail suppliers over here. From owner-freebsd-mobile Thu Sep 25 16:22:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA21392 for mobile-outgoing; Thu, 25 Sep 1997 16:22:12 -0700 (PDT) Received: from coconut.itojun.org (root@coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA21387 for ; Thu, 25 Sep 1997 16:22:03 -0700 (PDT) From: itojun@itojun.org Received: from localhost (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.8.5/3.6Wbeta6) with ESMTP id IAA01633; Fri, 26 Sep 1997 08:21:40 +0900 (JST) To: Mike Smith cc: mobile@FreeBSD.ORG In-reply-to: mike's message of Fri, 26 Sep 1997 03:06:24 +0930. <199709251736.DAA04935@word.smith.net.au> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Replacement dongle for 3C589? Date: Fri, 26 Sep 1997 08:21:40 +0900 Message-ID: <1629.875229700@coconut.itojun.org> Sender: owner-freebsd-mobile@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> However, the attachment cable costs almost $50, and brand-new >> ne2000-compatible PCMCIA card costs $70. Which do you choose? :-) >Hmm. Not so cheap here. Prices in Australian Dollars; which of these >would you recommend for adventure? >D-Link $138 (TP) >Socket $119 (TP) "D-Link DE650" and "Socket EA Lan Adapter" are listed in PAO supported cards, they will be probed as ed0. itojun From owner-freebsd-mobile Thu Sep 25 21:04:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA04981 for mobile-outgoing; Thu, 25 Sep 1997 21:04:14 -0700 (PDT) Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA04970 for ; Thu, 25 Sep 1997 21:04:05 -0700 (PDT) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id NAA00651; Fri, 26 Sep 1997 13:31:34 +0930 (CST) Message-Id: <199709260401.NAA00651@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Andrew Gordon cc: Mike Smith , mobile@freebsd.org Subject: Re: Replacement dongle for 3C589? In-reply-to: Your message of "Thu, 25 Sep 1997 23:54:50 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Sep 1997 13:31:32 +0930 From: Mike Smith Sender: owner-freebsd-mobile@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On Fri, 26 Sep 1997, Mike Smith wrote: > > > >Having just recovered my laptop after having had it stolen, I need to > > > >replace the dongle off the 3C589. I seem to recall stories about how > > > >hard this is - what experiences have people had with this? > > > >Anyone have a spare? 8) > > I have a spare RJ45 cable for a 3C589A/B (having mis-typed the product > code when attempting to order one for my 3C589_C_). You are welcome > to it if it happens to be what you wanted. Hmm, I hadn't realised that there was a difference; oops. I'm actually in need of one for a D. Begging the question "what are the differences between the two"? > The RJ45 ones (both flavours) are quite cheap; the BNC ones are about > 4 times the price (GBP 13 / GBP 48). By BNC you mean just BNC, or UTP/BNC combo? It sounds like these are very different from the combo pod on a C/D. > > NewMedia $159 (BNC, TP) > > Hypertec $149 (BNC, TP) > > D-Link $138 (TP) > > Alloy $139 (BNC, TP) > > Eagle $119 (TP) > > Socket $119 (TP) > > Topware $139 (BNC) > > Are you sure all of these are NE2000 compatible? By no means. All I have are names, numbers and media details. Many of the above are secondhand. I really need one with both BNC and TP, so it sounds like I'll need to look at the Alloy and Hypertec cards. > I have a NewMedia > "livewire" card, which has AMD 79C940 chipset (having read the datasheet > and discovered that it's completely different to the 79C960, I have > given up on this one). I also have an Eagle NE200 - despite its > seductively similar partnumber, this is _not_ NE2000 compatible. Ok, scratch those two. 8) > > (I haven't called 3Com, if indeed they have an Australian spares agent.) > > The cables are available ex-stock from ordinary retail suppliers over here. That's promising, but by no means indicative. 8) I only got this thing back because of the poor state of the spare-parts industry over here... mike From owner-freebsd-mobile Fri Sep 26 02:48:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA25336 for mobile-outgoing; Fri, 26 Sep 1997 02:48:39 -0700 (PDT) Received: from word.smith.net.au (word.smith.net.au [202.0.75.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA25328 for ; Fri, 26 Sep 1997 02:48:29 -0700 (PDT) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id TAA00875; Fri, 26 Sep 1997 19:14:52 +0930 (CST) Message-Id: <199709260944.TAA00875@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: itojun@itojun.org cc: Mike Smith , mobile@FreeBSD.ORG Subject: Re: Replacement dongle for 3C589? In-reply-to: Your message of "Fri, 26 Sep 1997 08:21:40 +0900." <1629.875229700@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Sep 1997 19:14:49 +0930 From: Mike Smith Sender: owner-freebsd-mobile@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > >> However, the attachment cable costs almost $50, and brand-new > >> ne2000-compatible PCMCIA card costs $70. Which do you choose? :-) I did some searching today; a replacement pod for the 3C589D will cost me AUD$150. By contrast, I can get an NE2000 clone card (Alloy) for about $95, so I think I'll do Just That. 8) > "D-Link DE650" and "Socket EA Lan Adapter" are listed in PAO supported > cards, they will be probed as ed0. OK; hopefully soon I will have an Alloy card to add to the list 8) mike From owner-freebsd-mobile Fri Sep 26 03:17:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA26872 for mobile-outgoing; Fri, 26 Sep 1997 03:17:12 -0700 (PDT) Received: from arg1.demon.co.uk (arg1.demon.co.uk [194.222.34.166]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA26867 for ; Fri, 26 Sep 1997 03:17:06 -0700 (PDT) Received: (from arg@localhost) by arg1.demon.co.uk (8.8.5/8.8.5) id LAA06061; Fri, 26 Sep 1997 11:16:48 +0100 (BST) Date: Fri, 26 Sep 1997 11:16:47 +0100 (BST) From: Andrew Gordon X-Sender: arg@server.arg.sj.co.uk To: Mike Smith cc: mobile@freebsd.org Subject: Re: Replacement dongle for 3C589? In-Reply-To: <199709260401.NAA00651@word.smith.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-mobile@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 26 Sep 1997, Mike Smith wrote: > Hmm, I hadn't realised that there was a difference; oops. I'm actually > in need of one for a D. Begging the question "what are the differences > between the two"? Different shape connector at the card end. > > > The RJ45 ones (both flavours) are quite cheap; the BNC ones are about > > 4 times the price (GBP 13 / GBP 48). > > By BNC you mean just BNC, or UTP/BNC combo? It sounds like these are > very different from the combo pod on a C/D. Since only ordered the RJ45 type, I can't tell you for sure; however, I note that the cards are only sold as RJ45-only or combo, and the difference in price is about the same as the difference between the RJ45 cable and the "BNC" cable, therefore I deduce that the "BNC" cable is in fact the combo adaptor! (never trust a catalogue). From owner-freebsd-mobile Fri Sep 26 04:00:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA28466 for mobile-outgoing; Fri, 26 Sep 1997 04:00:08 -0700 (PDT) Received: from word.smith.net.au (word.smith.net.au [202.0.75.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA28442 for ; Fri, 26 Sep 1997 04:00:02 -0700 (PDT) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id UAA01182; Fri, 26 Sep 1997 20:27:36 +0930 (CST) Message-Id: <199709261057.UAA01182@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Andrew Gordon cc: Mike Smith , mobile@freebsd.org Subject: Re: Replacement dongle for 3C589? In-reply-to: Your message of "Fri, 26 Sep 1997 11:16:47 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Sep 1997 20:27:34 +0930 From: Mike Smith Sender: owner-freebsd-mobile@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On Fri, 26 Sep 1997, Mike Smith wrote: > > Hmm, I hadn't realised that there was a difference; oops. I'm actually > > in need of one for a D. Begging the question "what are the differences > > between the two"? > > Different shape connector at the card end. Bugger. That prettymuch kills any hopes I had of converting yours to suit. 8( > Since only ordered the RJ45 type, I can't tell you for sure; however, > I note that the cards are only sold as RJ45-only or combo, and > the difference in price is about the same as the difference between > the RJ45 cable and the "BNC" cable, therefore I deduce that the > "BNC" cable is in fact the combo adaptor! (never trust a catalogue). Heh. The suppliers I called had comparable difficulty making sense out of their listings; it was somewhat of a shemozzle to say the least. Anyway, as previously mentioned, the cost of getting something usable around here is just ludicrous, so I'll shelve the D as a spare and go buy an NE2000 clone. mike From owner-freebsd-mobile Fri Sep 26 14:52:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA00794 for mobile-outgoing; Fri, 26 Sep 1997 14:52:44 -0700 (PDT) Received: from thorazine.neuron.net (thorazine.neuron.net [208.132.136.190]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA00789 for ; Fri, 26 Sep 1997 14:52:39 -0700 (PDT) Received: (from amir@localhost) by thorazine.neuron.net (8.8.7/8.8.6) id SAA24181; Fri, 26 Sep 1997 18:03:28 -0400 (EDT) Message-ID: <19970926180328.11052@neuron.net> Date: Fri, 26 Sep 1997 18:03:28 -0400 From: "Amir Y. Rosenblatt" To: freebsd-mobile@freebsd.org Subject: 3c589D and PAO on a Thinkpad 765D Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 Sender: owner-freebsd-mobile@freebsd.org X-Loop: FreeBSD.org Precedence: bulk So, I've got 2.2.2-R with the PAO patches applied installed on my Thinkpad 765D. It boots up fine, sees the card fine, picks the UTP port fine and then when it triews to add the default gateway complains "network unreachable". The green link light on the dongle from the card is on and the ifconfig looks dandy. I've tried swapping the "link0 -link1" in the pccard.conf entry to be "-link0", which, contrary to the man page, has always been what's gotten UTP working on every 3c509 card I've ever used under FreeBSD, but that too was to no avail. The card's worked flawlessly under 95 from day 1. Any ideas? -AMir -- / \ Madness takes it's toll. Please | Amir Y. Rosenblatt /<@>\ have exact change. - anon | amir@neuron.net / \ FNORD | http://www.neuron.net/~amir _/_______\____________________________________|____________________________ From owner-freebsd-mobile Fri Sep 26 15:13:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA01816 for mobile-outgoing; Fri, 26 Sep 1997 15:13:45 -0700 (PDT) Received: from sag.space.lockheed.com (sag.space.lockheed.com [192.68.162.134]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA01808 for ; Fri, 26 Sep 1997 15:13:40 -0700 (PDT) Received: from localhost by sag.space.lockheed.com; (5.65v3.2/1.1.8.2/21Nov95-0423PM) id AA13028; Fri, 26 Sep 1997 15:13:42 -0700 Date: Fri, 26 Sep 1997 15:13:42 -0700 (PDT) From: "Brian N. Handy" To: freebsd-mobile@freebsd.org Subject: TP560 Port Replicator Message-Id: X-Files: The truth is out there Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-mobile@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hey Folks! I whined last week about the --<-/+> bit last week for changing resolutions on the thinkpad. The problem for me was going to be when I plugged an external monitor into the TP and wanted to up my resolution to 1024x768. I've almost decided it's a red herring. It's still slightly annoying, but it seems to be a non-problem -- I plug in an external keyboard and all the functionality is there. I can change resolutions at will. The port replicator is pretty cool, but awful simple for the $250US you fork out for it. All it amounts to is a attachement gizmo that provides a clone of the back of the thinkpad -- cosmetically it's almost the same thing. So, you plug a mouse, keyboard and monitor into it and then just drop the laptop on it at will and viola, everything's there. Some rumours I've heard in the past is that there's a SCSI connector built into it and other stuff -- nope, nothing like that. You get nothing for Free here! You still have to plug in all the PCMCIA stuff that you want to use. Anyway, with a bit more fiddling with XF86Config I hope to have the monitor working at 1024x768. No luck yet, I can only get it to go in 600x400 right now. 800x600 won't lock. (This is on a Viewsonic P815, btw.) Happy trails, Brian From owner-freebsd-mobile Fri Sep 26 15:53:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA04560 for mobile-outgoing; Fri, 26 Sep 1997 15:53:49 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA04549 for ; Fri, 26 Sep 1997 15:53:36 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id QAA21271; Fri, 26 Sep 1997 16:53:28 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id QAA24468; Fri, 26 Sep 1997 16:53:26 -0600 (MDT) Date: Fri, 26 Sep 1997 16:53:26 -0600 (MDT) Message-Id: <199709262253.QAA24468@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Amir Y. Rosenblatt" Cc: freebsd-mobile@freebsd.org Subject: Re: 3c589D and PAO on a Thinkpad 765D In-Reply-To: <19970926180328.11052@neuron.net> References: <19970926180328.11052@neuron.net> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-mobile@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > So, I've got 2.2.2-R with the PAO patches applied installed on my Thinkpad > 765D. It boots up fine, sees the card fine, picks the UTP port fine and > then when it triews to add the default gateway complains "network > unreachable". The green link light on the dongle from the card is on and > the ifconfig looks dandy. I've tried swapping the "link0 -link1" in the > pccard.conf entry to be "-link0" Try "-link0 link1". Nate From owner-freebsd-mobile Fri Sep 26 18:07:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA11820 for mobile-outgoing; Fri, 26 Sep 1997 18:07:37 -0700 (PDT) Received: from polya.blah.org (slmel4p36.ozemail.com.au [203.108.201.124]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA11815 for ; Fri, 26 Sep 1997 18:07:32 -0700 (PDT) Received: (from ada@localhost) by polya.blah.org (8.8.6/8.8.5) id LAA05563 for mobile@freebsd.org; Sat, 27 Sep 1997 11:07:28 +1000 (EST) From: Ada T Lim Message-Id: <199709270107.LAA05563@polya.blah.org> Subject: Re: TP560 Port Replicator In-Reply-To: from "Brian N. Handy" at "Sep 26, 97 03:13:42 pm" To: handy@sag.space.lockheed.com (Brian N. Handy) Date: Sat, 27 Sep 1997 11:07:09 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-mobile@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > The port replicator is pretty cool, but awful simple for the $250US you > fork out for it. All it amounts to is a attachement gizmo that provides a > clone of the back of the thinkpad -- cosmetically it's almost the same > thing. So, you plug a mouse, keyboard and monitor into it and then just > drop the laptop on it at will and viola, everything's there. Some rumours > I've heard in the past is that there's a SCSI connector built into it and > other stuff -- nope, nothing like that. You get nothing for Free here! > You still have to plug in all the PCMCIA stuff that you want to use. The port replicators don't do this. What you want is the Selecta-Dock I/II, which contains 1 or 2 PCI slots, a SCSI controller, and a drive bay or two, I think. Oh, and they do port replication too. However, these are awfully expensive - all up almost $1k US, which is like enough to build a second machine and do everything over ether. Ada From owner-freebsd-mobile Sat Sep 27 17:02:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA21775 for mobile-outgoing; Sat, 27 Sep 1997 17:02:23 -0700 (PDT) Received: from sag.space.lockheed.com (sag.space.lockheed.com [192.68.162.134]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id RAA21769 for ; Sat, 27 Sep 1997 17:02:19 -0700 (PDT) Received: from localhost by sag.space.lockheed.com; (5.65v3.2/1.1.8.2/21Nov95-0423PM) id AA21880; Sat, 27 Sep 1997 17:02:18 -0700 Date: Sat, 27 Sep 1997 17:02:18 -0700 (PDT) From: "Brian N. Handy" Reply-To: "Brian N. Handy" To: freebsd-mobile@freebsd.org Subject: Default routes? Message-Id: X-Files: The truth is out there Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-mobile@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hey folks, I'm setting up another laptop here with the box stock FreeBSD distribution, and ... I may just be tired or I may have a real question. If I insert my ethernet card, how does the default route get set up? I believe in a normal desktop this gets set up in rc.network with the defaultrouter variable from rc.conf. But this just doesn't work since the pccard isn't up and running yet typically. Brazen suggestion: should we do this in pccard_ether? Then have a variable like pccard_defaultrouter? Or does it normally get handled in some other more correct place? Thanks, Brian From owner-freebsd-mobile Sat Sep 27 18:44:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA26126 for mobile-outgoing; Sat, 27 Sep 1997 18:44:06 -0700 (PDT) Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA26102 for ; Sat, 27 Sep 1997 18:43:59 -0700 (PDT) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id LAA03219; Sun, 28 Sep 1997 11:11:24 +0930 (CST) Message-Id: <199709280141.LAA03219@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Brian N. Handy" cc: freebsd-mobile@freebsd.org Subject: Re: Default routes? In-reply-to: Your message of "Sat, 27 Sep 1997 17:02:18 MST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 28 Sep 1997 11:11:22 +0930 From: Mike Smith Sender: owner-freebsd-mobile@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I'm setting up another laptop here with the box stock FreeBSD > distribution, and ... I may just be tired or I may have a real question. No, it's real and somewhat of a key one. > If I insert my ethernet card, how does the default route get set up? It doesn't. Yet. > Brazen suggestion: should we do this in pccard_ether? Then have a > variable like pccard_defaultrouter? Or does it normally get handled in > some other more correct place? For now, do it in pccard_ether as a hack to get yourself going. I am in the process of writing a new rc.interface script which is to be called when an interface arrives/departs, which will obviate this, but it's not yet ready for primetime. mike From owner-freebsd-mobile Sat Sep 27 19:44:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA00582 for mobile-outgoing; Sat, 27 Sep 1997 19:44:53 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA00577 for ; Sat, 27 Sep 1997 19:44:47 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id UAA02555; Sat, 27 Sep 1997 20:44:45 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id UAA28757; Sat, 27 Sep 1997 20:44:42 -0600 (MDT) Date: Sat, 27 Sep 1997 20:44:42 -0600 (MDT) Message-Id: <199709280244.UAA28757@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Brian N. Handy" Cc: freebsd-mobile@freebsd.org Subject: Re: Default routes? In-Reply-To: References: X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-mobile@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > If I insert my ethernet card, how does the default route get set up? ... > Brazen suggestion: should we do this in pccard_ether? Umm, it *used* to be done there, or at least I have it there on my box. Maybe I never committed the code. :( Nate From owner-freebsd-mobile Sat Sep 27 20:08:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA01758 for mobile-outgoing; Sat, 27 Sep 1997 20:08:27 -0700 (PDT) Received: from coconut.itojun.org (root@coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA01751 for ; Sat, 27 Sep 1997 20:08:23 -0700 (PDT) From: itojun@itojun.org Received: from localhost (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.8.5/3.6Wbeta6) with ESMTP id MAA24132; Sun, 28 Sep 1997 12:08:01 +0900 (JST) To: Nate Williams cc: "Brian N. Handy" , freebsd-mobile@FreeBSD.ORG In-reply-to: nate's message of Sat, 27 Sep 1997 20:44:42 CST. <199709280244.UAA28757@rocky.mt.sri.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Default routes? Date: Sun, 28 Sep 1997 12:08:01 +0900 Message-ID: <24128.875416081@coconut.itojun.org> Sender: owner-freebsd-mobile@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> If I insert my ethernet card, how does the default route get set up? >... >> Brazen suggestion: should we do this in pccard_ether? >Umm, it *used* to be done there, or at least I have it there on my box. >Maybe I never committed the code. :( If you have PAO package installed, this will be done in /etc/pccard_ether. example file will come with PAO tarball. follow links from http://www.mt.cs.keio.ac.jp/person/hosokawa.html. itojun From owner-freebsd-mobile Sat Sep 27 21:35:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA05834 for mobile-outgoing; Sat, 27 Sep 1997 21:35:16 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA05805 for ; Sat, 27 Sep 1997 21:34:59 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id WAA03280; Sat, 27 Sep 1997 22:34:46 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id WAA29350; Sat, 27 Sep 1997 22:34:44 -0600 (MDT) Date: Sat, 27 Sep 1997 22:34:44 -0600 (MDT) Message-Id: <199709280434.WAA29350@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: itojun@itojun.org Cc: Nate Williams , "Brian N. Handy" , freebsd-mobile@freebsd.org Subject: Re: Default routes? In-Reply-To: <24128.875416081@coconut.itojun.org> References: <199709280244.UAA28757@rocky.mt.sri.com> <24128.875416081@coconut.itojun.org> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-mobile@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> If I insert my ethernet card, how does the default route get set up? > >... > >> Brazen suggestion: should we do this in pccard_ether? > >Umm, it *used* to be done there, or at least I have it there on my box. > >Maybe I never committed the code. :( > > If you have PAO package installed, this will be done in > /etc/pccard_ether. I don't use the PAO patches. I mentioned this a long time ago, and may have even sent the patches to the mobile list. Apparently I forgot to actually commit it. :( Nate