Re: ISA on EISA.
On Sun, Nov 12, 2000 at 02:37:02PM +0200, petro wrote: Hello! I have the following question I had Compaq Proliant with 5 EISA slots and I would like to insert into it ISA cards. Is it possible or it is unpossible, if possible where I can read about this. EISA slots can accomodate ISA cards. Please run the SCU/ECU utility to tell your EISA system BIOS what resources (irq, ioranges etc) your ISA card uses. -- Wilko Bulte Arnhem, the Netherlands [EMAIL PROTECTED] http://www.freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB-to-SCSI converter
* Nick Hibma ([EMAIL PROTECTED]) [001112 06:01]: I don't know. The only thing I know is that the protocol on the USB wire does not let you select the SCSI id, just the LUN. I've confirmed that under Windows this cable works with any SCSI ID, but only if you install the Microtech driver. Otherwise, it doesn't show up (i.e. identical to FBSD). Presuming that their driver is actually just a ID mapping layer, would the same thing be feasible under BSD? I'll fire off a note to their support people and see if they can at least confirm my line of thinking here. -- j. James FitzGibbon [EMAIL PROTECTED] Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [OT] serial protocol analyzer
In article [EMAIL PROTECTED], kf [EMAIL PROTECTED] wrote: I don't remember the url anymore, but I do remember that there was a Japanese guy who wrote drivers for digital cameras, cameras which connected to the serial port of a PC to download the pictures. On his site he mentioned a (free?) package which he used to analyze the "conversation" between the camera and the PC. Right. That's the "comms/snooper" port that I recommended. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
PPPoE w/ nat auto fragmentation hack?
Hi, Any of you happened to hack the PPPoE support on Fbsd 4.x to automatically fragment the IP datagram if whatever device behind the NAT refuses to adjust its MTU? Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PPPoE w/ nat auto fragmentation hack?
Hi, Any of you happened to hack the PPPoE support on Fbsd 4.x to automatically fragment the IP datagram if whatever device behind the NAT refuses to adjust its MTU? There's a ``tcpmssd'' port. Thanks -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ISA on EISA.
Hello! I have the following question I had Compaq Proliant with 5 EISA slots and I would like to insert into it ISA cards. Is it possible or it is unpossible, if possible where I can read about this. For the most part, yes. I've ran across one or two places where ISA cards won't run in EISA slots but that was mostly with Packard Bell and Acer. Rick *** Rick's FreeBSD Web page http://heorot.1nova.com/freebsd Ace Logan's Hardware Guide http://www.shatteredcrystal.net/hardware ***FreeBSD - The Power to Serve! http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
KLDs and PCI?
I am working on a KLD for a PCI device. My problem is I can't find how to call the probe and attach calls during the load for a PCI device. I have looked in the /usr/src/sys/pci directory and haven't found any KLDs to use as an example. What are the steps I need to take to handle a PCI device in a KLD? Are there any examples I can look out? Oh yeah, I am doing this for a FreeBSD 3.x system (I know, but is needed for this project, it will be ported to 4.x later) - Chris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
pci bus enumeration cdevsw indexing
I'm new to FreeBSD, but an experienced kernel guy. I'm workgin with
4.1.1 on IA32 and need help understanding the ways of your world. :-)
I'd like my project to look like a "normal" driver and use supported
interfaces, but I'll patch the core code if I need to.
I have a need to walk the PCI bus, gleaning PCI IDs and other data.
(Yes, I know a dozen reasons why to NOT do that.) What I *almost*
need is the loop in pci_ioctl that walks pci_dev[]. The catch here is
that this is a private data structure (static, lots of dependencies on
private headers not in sys/..., etc) and therefore unavailable. I
considered calling the ioctl code myself from withing my driver, but
that seems too weird. I thought about shipping the data to myself by
way of user-space (daemon does an ioctl ('pciconf -l'ish) to PCI driver,
turns around and hands data to me on an ioctl) but that sounds like an
application to be punished.
Is there a "normal" way for a conforming driver to walk the busses,
pluck out bus number, slot number, device id, subsystem id, and all that
traditional stuff, or do I just need to carve up pci.c and build my own
interface to do it?
Also, I have a question on loadable character devices. Is there a way
to avoid the hard-coded major numbers in the cdevsw[] entry that's
passed? It seems like make_dev() should be able to roam cdevsw, find
an empty slot, and create the dev nodes for me. I'm envisioning a very
dynamic system with lots of modules (enough that we really don't want to
allocate them with a human involved) being popped in and out and would
like to not handle the major number management and inevitable conflicts
on my own.
How is this handled for, say, third-party drivers?
Thanx for any help offered.
RJL
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: pci bus enumeration cdevsw indexing
On Mon, Nov 13, 2000 at 00:44:10 -0600, Robert Lipe wrote:
I'm new to FreeBSD, but an experienced kernel guy. I'm workgin with
4.1.1 on IA32 and need help understanding the ways of your world. :-)
I'd like my project to look like a "normal" driver and use supported
interfaces, but I'll patch the core code if I need to.
I have a need to walk the PCI bus, gleaning PCI IDs and other data.
(Yes, I know a dozen reasons why to NOT do that.) What I *almost*
need is the loop in pci_ioctl that walks pci_dev[]. The catch here is
that this is a private data structure (static, lots of dependencies on
private headers not in sys/..., etc) and therefore unavailable. I
considered calling the ioctl code myself from withing my driver, but
that seems too weird. I thought about shipping the data to myself by
way of user-space (daemon does an ioctl ('pciconf -l'ish) to PCI driver,
turns around and hands data to me on an ioctl) but that sounds like an
application to be punished.
Is there a "normal" way for a conforming driver to walk the busses,
pluck out bus number, slot number, device id, subsystem id, and all that
traditional stuff, or do I just need to carve up pci.c and build my own
interface to do it?
Well, it might help if we understood a little more about why you want to
look at all the devices on the PCI bus. There are certainly plenty of
reasons to do it, but there may be other/better ways to get the
functionality you need. (I've done it from userland, FWIW. I also
wrote the current PCIOCGETCONF code.) What does your driver do?
If you do need to get at the data, the easiest thing to do would be to
un-staticize pci_devq (in pci.c), and include pci/pcivar.h in your program,
to get the definition for struct pci_devinfo.
If this is an embedded-type project that's going to involve shipping
already-compiled code, I wouldn't worry too much about modifying the PCI
code. If this is a driver you're going to want to ship in source or module
form, we'll likely need to work out how you're going to do it (i.e. what
changes will go into the tree), so the module or driver will work when it
is loaded or compiled.
[ ...major numbers for loadable devices... ]
Someone who knows more about modules can answer that one...
Ken
--
Kenneth Merry
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
