Re: PNP ids missing in sio.c
On Sat, 04 Sep 1999 21:34:09 -0700, Mike Smith [EMAIL PROTECTED] said: The enumerator should assign these resources to a placeholder; I was thinking the nexus was as good an owner as any. If there's an "unknown" device that's probably even better. Some of them should be claimed by real devices -- for example, the pseudo-i8237 ISA DMA controller should be claimed by the ISA bus (which I don't think it does now, unless someone added the code to do it while I wasn't looking). Similarly the PIC, the PIT, the RTC, and other random bits of ``Industry Standard'' hardware. It might even be worth having these be their own unique devices, just to help diagnosis if they ever go away... Yes please please please. Those of us doing strange stuff with strange machines would be eternally greatful if there were device nodes for PIC's, PIT's, RTC's and ``other random bits''. Note that though the ISA standard only has 1 of each of these in them, some really crazy hardware guys like me know all to well how to add anyone of them to an existing design. I have had x86 boxen with 4 PIC's in them and had to hand glue the interrupt code togeather to deal with it. I don't really care if the interrupt code is ever tought about this stuff, but at least having the device code know about these devices and report there existence goes a long way to dealing with these strange systems. Multi PIT's are extreamly useful, and I think there have already been some hooks added by either bde or phk to deal with a real hardware stat clock, having a real PIT driver would make a $10.00 add in PIT card possible for FreeBSD. Also note that some of these devices are already special cased and actually have multiple devices inside of them, infact the PIC and DMA are really 2 physical devices in the original design, just the cascade line is common. rtc0 at 0x040 on isa rtc1 at 0x048 on isa pic0 at 0x020 on isa pic1 at 0x0a0 on isa dmapg0 at 0x080 on isa dma0 at 0x000 on isa dma1 at 0x0c0 on isa -- Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PNP ids missing in sio.c
On Sat, 4 Sep 1999, Chuck Robey wrote: Does the sio driver know about PCI? Can it run PCI sio cards, like those sold by SIIG? Not at the moment. I don't know anything about these cards. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PNP ids missing in sio.c
On Sat, 4 Sep 1999, Mike Smith wrote: I'm curious what can be made of the PNP resource list we get from the BIOS at boot time... It lists motherboard resources too, we could probably end up with a fairly complete map of known resources to avoid. I bet we can roll another enumerator similar to pnp.c which takes the bios output and turns it into devices. It would mean removing all the probe hints from your kernel config to avoid confusion but apart from that it should work really well. This is one reason why I think that the PnP scan should be done _before_ the legacy scan; there are cases where the legacy scan is going to find stuff that the PnP enumerator also knows about. If the PnP enumerator has already found it, then the legacy scan aborts; in the reverse situation the PnP enumerator has no way of knowing that the device has already been claimed. As for the BIOS PnP info; all I'm doing at the moment is scanning for device and compat IDs. Since the information is formatted in exactly the same fashion as ISA PnP data, I was hoping to actually dump the current pointless scan and hook the BIOS access method into the new PnP code. Another argument for making the PnP scan first is that the BIOS identifies a whole pile of "do not go there" regions which you don't want anything, even a legacy device probe, looking at. Its a difficult problem. If you run the heuristic probes first, then one of them might pick up a device intended for a pnp driver. On the other hand if you don't run the heuristic probes first, you have no idea what resource regions to avoid when allocating resources for pnp devices. Surely with a working pnpbios *all* devices become pnp devices which solves the problem quite neatly. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PNP ids missing in sio.c
On Sun, 5 Sep 1999, Garrett Wollman wrote: On Sat, 04 Sep 1999 21:34:09 -0700, Mike Smith [EMAIL PROTECTED] said: The enumerator should assign these resources to a placeholder; I was thinking the nexus was as good an owner as any. If there's an "unknown" device that's probably even better. Some of them should be claimed by real devices -- for example, the pseudo-i8237 ISA DMA controller should be claimed by the ISA bus (which I don't think it does now, unless someone added the code to do it while I wasn't looking). Similarly the PIC, the PIT, the RTC, and other random bits of ``Industry Standard'' hardware. It might even be worth having these be their own unique devices, just to help diagnosis if they ever go away... Reserving resources for these things is on my TODO list. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PNP ids missing in sio.c
Doug Rabson wrote: On Sat, 4 Sep 1999, Mike Smith wrote: I'm curious what can be made of the PNP resource list we get from the B IOS at boot time... It lists motherboard resources too, we could probably end up with a fairly complete map of known resources to avoid. I bet we can roll another enumerator similar to pnp.c which takes the bio s output and turns it into devices. It would mean removing all the probe hints from your kernel config to avoid confusion but apart from that it should work really well. This is one reason why I think that the PnP scan should be done _before_ the legacy scan; there are cases where the legacy scan is going to find stuff that the PnP enumerator also knows about. If the PnP enumerator has already found it, then the legacy scan aborts; in the reverse situation the PnP enumerator has no way of knowing that the device has already been claimed. As for the BIOS PnP info; all I'm doing at the moment is scanning for device and compat IDs. Since the information is formatted in exactly the same fashion as ISA PnP data, I was hoping to actually dump the current pointless scan and hook the BIOS access method into the new PnP code. Another argument for making the PnP scan first is that the BIOS identifies a whole pile of "do not go there" regions which you don't want anything, even a legacy device probe, looking at. Its a difficult problem. If you run the heuristic probes first, then one of them might pick up a device intended for a pnp driver. On the other hand if you don't run the heuristic probes first, you have no idea what resource regions to avoid when allocating resources for pnp devices. Surely with a working pnpbios *all* devices become pnp devices which solves the problem quite neatly. One big problem that we see right now is best described with an example. Suppose a system has a PnP soundblaster clone card. The BIOS configures it at default settings. The user has a pcm0 at isa? foo. The ISA probe is run first and "sees" the leftovers from the pnp bios and attaches. Later the pnp probe runs and *moves* the pnp device out from underneath the isa driver and reattaches it elsewhere. The "solution" that I see is for the isa probe to disable all the pnp devices it can first before starting the isa device probe. Then the pnp cards will be out of harms way while the isa probe runs and then can be configured to work around the old-style isa cards. That means that the isa drivers won't be able to probe compatable pnp cards that are just missing an ID match. I see the "solution" to that as an override system that enables a user-defined ID match to be bound to an isa device. Eg: specifically add (via userconfig-ng) PNP1234 to the pcm/sb driver. This could be a bit tricky to get right but might work out for legacy stuff with wierd ID's. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PNP ids missing in sio.c
On Sun, 5 Sep 1999, Peter Wemm wrote: Doug Rabson wrote: On Sat, 4 Sep 1999, Mike Smith wrote: I'm curious what can be made of the PNP resource list we get from the B IOS at boot time... It lists motherboard resources too, we could probably end up with a fairly complete map of known resources to avoid. I bet we can roll another enumerator similar to pnp.c which takes the bio s output and turns it into devices. It would mean removing all the probe hints from your kernel config to avoid confusion but apart from that it should work really well. This is one reason why I think that the PnP scan should be done _before_ the legacy scan; there are cases where the legacy scan is going to find stuff that the PnP enumerator also knows about. If the PnP enumerator has already found it, then the legacy scan aborts; in the reverse situation the PnP enumerator has no way of knowing that the device has already been claimed. As for the BIOS PnP info; all I'm doing at the moment is scanning for device and compat IDs. Since the information is formatted in exactly the same fashion as ISA PnP data, I was hoping to actually dump the current pointless scan and hook the BIOS access method into the new PnP code. Another argument for making the PnP scan first is that the BIOS identifies a whole pile of "do not go there" regions which you don't want anything, even a legacy device probe, looking at. Its a difficult problem. If you run the heuristic probes first, then one of them might pick up a device intended for a pnp driver. On the other hand if you don't run the heuristic probes first, you have no idea what resource regions to avoid when allocating resources for pnp devices. Surely with a working pnpbios *all* devices become pnp devices which solves the problem quite neatly. One big problem that we see right now is best described with an example. Suppose a system has a PnP soundblaster clone card. The BIOS configures it at default settings. The user has a pcm0 at isa? foo. The ISA probe is run first and "sees" the leftovers from the pnp bios and attaches. Later the pnp probe runs and *moves* the pnp device out from underneath the isa driver and reattaches it elsewhere. The "solution" that I see is for the isa probe to disable all the pnp devices it can first before starting the isa device probe. Then the pnp cards will be out of harms way while the isa probe runs and then can be configured to work around the old-style isa cards. This would work well with the existing 'hardware' pnp driver since it supports disabling devices already. It would probably be good enough for a future pnpbios driver too. That means that the isa drivers won't be able to probe compatable pnp cards that are just missing an ID match. I see the "solution" to that as an override system that enables a user-defined ID match to be bound to an isa device. Eg: specifically add (via userconfig-ng) PNP1234 to the pcm/sb driver. This could be a bit tricky to get right but might work out for legacy stuff with wierd ID's. This seems feasable. We will have to decide soon what this userconfig-ng thing will look like... -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PNP ids missing in sio.c
On Fri, 3 Sep 1999, Steve Price wrote: Can anyone think of a good reason why I can't migrate the old PNP ids to the new sio.c? I just rebooted my box with a fresh kernel and much to my shagrin (sp?) my USR PNP modem didn't work anymore. The following patch got it working again. The reason I didn't move the old ids wholesale is that the old system matched against the vendor id (which is bogus for multifunction cards). The new system matches with the logical device id which is often different from the vendor id. Some simple single function cards use the same id for both (as yours does) but I can't tell this without seeing the pnpinfo output. Now that we can't use the pnp command from 'boot -c', what has (if anything) replaced it? I seem to be remember this being discussed recently but I'll be darned if I can find it in the mailing list archives. The pnp command should no longer be needed (crossed fingers) since the new code automatically detects devices and assigns resources to them. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PNP ids missing in sio.c
On Sat, Sep 04, 1999 at 10:21:51AM +0100, Doug Rabson wrote: The pnp command should no longer be needed (crossed fingers) since the new code automatically detects devices and assigns resources to them. What about the situation where: pnp sound card (soundblaster awe64). non pnp network card (irq 5, port 0x300, setup ability unknown -- even windows can't properly find it without help) Although I just replaced that network card last week (etherexpress 100+), and replaced the soundblaster (with a pci es1370 based card) this might be an issue for others. The BIOS put the sound card on irq 9, ports 0x220, 0x330, 0x388, 0x620/0xa20/0xe20, and drqs 1,7 ... (this was fine), but the new pnp code insisted on changing the sound card to irq 5, same ports, and drqs 1,5 even though the bios had configured it somewhere else. The network card used the 'ed' driver, so that device wasn't compiled in the kernel right after the the switchover (but it still conflicted with the sound card until I yanked it). This is of course a special case, a cranky network card and a non-compiling driver for it. If the new pnp code avoids using resources hard-wired to non-pnp isa devices (it may, I changed hardware before the code was fixed), there shouldn't be any problems. It was an excellent excuse to boot that nic anyway. -- Zach Heilig [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PNP ids missing in sio.c
On Sat, 4 Sep 1999, Zach N. Heilig wrote: On Sat, Sep 04, 1999 at 10:21:51AM +0100, Doug Rabson wrote: The pnp command should no longer be needed (crossed fingers) since the new code automatically detects devices and assigns resources to them. What about the situation where: pnp sound card (soundblaster awe64). non pnp network card (irq 5, port 0x300, setup ability unknown -- even windows can't properly find it without help) Although I just replaced that network card last week (etherexpress 100+), and replaced the soundblaster (with a pci es1370 based card) this might be an issue for others. The BIOS put the sound card on irq 9, ports 0x220, 0x330, 0x388, 0x620/0xa20/0xe20, and drqs 1,7 ... (this was fine), but the new pnp code insisted on changing the sound card to irq 5, same ports, and drqs 1,5 even though the bios had configured it somewhere else. The network card used the 'ed' driver, so that device wasn't compiled in the kernel right after the the switchover (but it still conflicted with the sound card until I yanked it). This is of course a special case, a cranky network card and a non-compiling driver for it. If the new pnp code avoids using resources hard-wired to non-pnp isa devices (it may, I changed hardware before the code was fixed), there shouldn't be any problems. It was an excellent excuse to boot that nic anyway. The trick for this is to make sure that the config file contains accurate descriptions of all your non-pnp hardware. In this case, if you have: device ed0 at isa? port 0x300 irq 5 ... then the subsequent pnp probes should avoid those port and irq settings. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PNP ids missing in sio.c
On Sat, 4 Sep 1999, Doug Rabson wrote:
# The reason I didn't move the old ids wholesale is that the old system
# matched against the vendor id (which is bogus for multifunction cards).
# The new system matches with the logical device id which is often different
# from the vendor id. Some simple single function cards use the same id for
# both (as yours does) but I can't tell this without seeing the pnpinfo
# output.
For others who are interested here's the old list. I can vouche
for the USR3031. If anyone else has one of the others or a PNP
modem/sio card not listed here, can you send me the output of
pnpinfo? I'll compile the list for my commit and forward it to
you Doug if you'd like.
{ 0x5015f435, "MOT1550"},
{ 0x8113b04e, "Supra1381"},
{ 0x9012b04e, "Supra1290"},
{ 0x7121b04e, "SupraExpress 56i Sp"},
{ 0x11007256, "USR0011"},
{ 0x30207256, "USR2030"},
{ 0x31307256, "USR3031"},
{ 0x90307256, "USR3090"},
{ 0x0100440e, "Cardinal MVP288IV"},
#
# Now that we can't use the pnp command from 'boot -c', what
# has (if anything) replaced it? I seem to be remember this
# being discussed recently but I'll be darned if I can find
# it in the mailing list archives.
#
# The pnp command should no longer be needed (crossed fingers) since the new
# code automatically detects devices and assigns resources to them.
So what happens if someone wants to "wire" down a device? It
was no big deal for me that it used to be sio1 and is now sio4,
but one should be able to imagine a scenario (just like with
SCSI disks?) that you'd need to be explicit about what resources
and device number the card gets. Of course I could be dead wrong
too. :-)
-steve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: PNP ids missing in sio.c
Doug Rabson wrote: On Sat, 4 Sep 1999, John-Mark Gurney wrote: Doug Rabson scribbled this message on Sep 4: This is of course a special case, a cranky network card and a non-compiling driver for it. If the new pnp code avoids using resource s hard-wired to non-pnp isa devices (it may, I changed hardware before th e code was fixed), there shouldn't be any problems. It was an excellent excuse to boot that nic anyway. The trick for this is to make sure that the config file contains accurate descriptions of all your non-pnp hardware. In this case, if you have: device ed0 at isa? port 0x300 irq 5 ... then the subsequent pnp probes should avoid those port and irq settings. but the problem is that he couldn't have the line in because the driver wouldn't compile... so are we going to add a dummy isa device that takes up resources so that this won't happen again? maybe the user has some win95 only isa card or something... but this needs to be able to be configured... along w/ doing this at boot -c time too... We already have a dummy driver (unknown) which can be adapted for this purpose. Perhaps this is the best solution. I'm curious what can be made of the PNP resource list we get from the BIOS at boot time... It lists motherboard resources too, we could probably end up with a fairly complete map of known resources to avoid. dmesg from boot -v: bios32: Found BIOS32 Service Directory header at 0xc00fd9e0 bios32: Entry = 0xfd9f0 (c00fd9f0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xda11 pnpbios: Found PnP BIOS data at 0xc00fa020 pnpbios: Entry = f:a120 Rev = 1.0 pnpbios: 36624 devices, largest 247 bytes pnpbios: handle 0 device ID PNP (d041) pnpbios: handle 1 device ID PNP0201 (0102d041) pnpbios: handle 2 device ID PNP0100 (0001d041) pnpbios: handle 3 device ID PNP0b00 (000bd041) pnpbios: handle 4 device ID PNP0800 (0008d041) pnpbios: handle 5 device ID PNP0c04 (040cd041) pnpbios: handle 6 device ID PNP0303 (0303d041) pnpbios: handle 7 device ID PNP0f13 (130fd041) pnpbios: handle 8 device ID PNP0c01 (010cd041) pnpbios: handle 9 device ID PNP0a03 (030ad041) pnpbios: handle 10 device ID PNP0700 (0007d041) pnpbios: handle 11 device ID PNP0401 (0104d041) pnpbios: handle 12 device ID PNP0501 (0105d041) pnpbios: handle 13 device ID PNP0501 (0105d041) pnpbios: handle 14 device ID PNP0c02 (020cd041) pnpbios: handle 15 device ID PNP0c02 (020cd041) Other BIOS signatures found: ACPI: disk1s1a: pnpscan -v Probing PnP BIOS... Probing ISA bus... Probing PCI BIOS... PNP scan summary: PNP PNP0201 PNP0100 PNP0b00 PNP0800 PNP0c04 PNP0303 PNP0f13 PNP0c01 PNP0a03 PNP0700 PNP0401 PNP0501 PNP0501 PNP0c02 PNP0c02 CSC0b36 : CS4236 Audio 0x80789004 : SCSI controller 0x70108086 : IDE controller 0x12298086 : Ethernet controller 0x70208086 : USB controller I'm not sure if the boot time scan is supposed to see the Sound device as well as the PCI devices or not. pcm0: CS4236 at port 0x534-0x537,0x388-0x38b,0x220-0x22f irq 5 drq 1,0 on isa0 Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PNP ids missing in sio.c
On Sat, 4 Sep 1999, Doug Rabson wrote: On Fri, 3 Sep 1999, Steve Price wrote: Can anyone think of a good reason why I can't migrate the old PNP ids to the new sio.c? I just rebooted my box with a fresh kernel and much to my shagrin (sp?) my USR PNP modem didn't work anymore. The following patch got it working again. The reason I didn't move the old ids wholesale is that the old system matched against the vendor id (which is bogus for multifunction cards). The new system matches with the logical device id which is often different from the vendor id. Some simple single function cards use the same id for both (as yours does) but I can't tell this without seeing the pnpinfo output. Now that we can't use the pnp command from 'boot -c', what has (if anything) replaced it? I seem to be remember this being discussed recently but I'll be darned if I can find it in the mailing list archives. The pnp command should no longer be needed (crossed fingers) since the new code automatically detects devices and assigns resources to them. Does the sio driver know about PCI? Can it run PCI sio cards, like those sold by SIIG? -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd.Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message ---+--- Chuck Robey| Interests include any kind of voice or data [EMAIL PROTECTED] | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770| picnic.mat.net: FreeBSD/i386 (301) 220-2114 | jaunt.mat.net : FreeBSD/Alpha ---+--- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PNP ids missing in sio.c
I'm curious what can be made of the PNP resource list we get from the BIOS at boot time... It lists motherboard resources too, we could probably end up with a fairly complete map of known resources to avoid. I bet we can roll another enumerator similar to pnp.c which takes the bios output and turns it into devices. It would mean removing all the probe hints from your kernel config to avoid confusion but apart from that it should work really well. This is one reason why I think that the PnP scan should be done _before_ the legacy scan; there are cases where the legacy scan is going to find stuff that the PnP enumerator also knows about. If the PnP enumerator has already found it, then the legacy scan aborts; in the reverse situation the PnP enumerator has no way of knowing that the device has already been claimed. As for the BIOS PnP info; all I'm doing at the moment is scanning for device and compat IDs. Since the information is formatted in exactly the same fashion as ISA PnP data, I was hoping to actually dump the current pointless scan and hook the BIOS access method into the new PnP code. Another argument for making the PnP scan first is that the BIOS identifies a whole pile of "do not go there" regions which you don't want anything, even a legacy device probe, looking at. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PNP ids missing in sio.c
On Sat, 04 Sep 1999 21:34:09 -0700, Mike Smith [EMAIL PROTECTED] said: The enumerator should assign these resources to a placeholder; I was thinking the nexus was as good an owner as any. If there's an "unknown" device that's probably even better. Some of them should be claimed by real devices -- for example, the pseudo-i8237 ISA DMA controller should be claimed by the ISA bus (which I don't think it does now, unless someone added the code to do it while I wasn't looking). Similarly the PIC, the PIT, the RTC, and other random bits of ``Industry Standard'' hardware. It might even be worth having these be their own unique devices, just to help diagnosis if they ever go away... -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PNP ids missing in sio.c
ummm... I thought that the plan was to disable all PnP devices, do the legacy isa probes, and then reenable the PnP devices and probe them... The fact that a device is reported via PnP does not guarantee that you can disable it. Most of the "devices" reported by the PnP BIOS can neither be disabled nor moved. that way you don't have the problem of legacy probes grabing a card... It doesn't avoid attempting to probe for a legacy device in a region where a fixed but PnP-known device exists. I forgot to mention that it also doesn't deal with the case where a legacy device exists but is not described by the kernel's static metadata. There are several ways to work around this issue; in the ISA case one should use the port availibility determination technique described in the ISA PnP spec (or an equivalent) as well as the ESCD information available from the PnP BIOS. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PNP ids missing in sio.c
Steve Price wrote: Now that we can't use the pnp command from 'boot -c', what has (if anything) replaced it? I seem to be remember this being discussed recently but I'll be darned if I can find it in the mailing list archives. The old pnp code is fundamentally incompatable with the new pnp code and has gone. Doug's new pnp code is tightly integrated within the isa bus and is rather smart. It will choose it's own non-conflicting addresses for the devices. There isn't much use for the userconfig pnp command as the pnp devices are deactivated during the ISA probes and only switched on when a device claims them, based on their PNP id. Basically this means we've got to pay a lot more attention to the PNP id and compat id's now. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
